Today most software products are highly networked and distributed solutions used by 1000s if not -10000s of people spread across the globe. To produce an experience that is intuitive and delivers a quality service worldwide, multi-culturally, and 24/7 across all time zones, you need a multi-disciplinary and diverse set of individuals i.e. a tailored team. Join us in this panel with: Dawn Ahukanna, Nivia Henry, Jessica Kerr, Ruth Malan, Rebecca Wirfs-Brock, Mathias Verraes, Trond Hjorteland
There is a quote made famous by Ruth Malan from Grady Booch: 'Architecture represents the significant design decisions that shape a system.' And shaping a system takes time, and seeing the impact of these significant design decisions can take years after the changes have been done. And most of us are usually not there to reak the benefit, or worse, feel its pain. So in collaboration with D-EDGE we will have a panel of people that did experience and will discuss how architecture decisions shaped the system years after the change. About D-EDGE Have you ever booked a hotel online? Then you've probably used D-EDGE without knowing it. Every day, we help more than 17,000 hotels worldwide to develop their online visibility and sales through a range of SaaS and digital marketing solutions. Amongst the 480 D-EDGERS, the R&D team is made up of a hundred or so enthusiasts who are reinventing hotel booking for both the traveller and the hotelier. As a subsidiary of the Accor group, D-EDGE simplifies the life of independent hotels and hotel chains alike. https://www.meetup.com/D-EDGE-tech/ https://miro.com/app/board/uXjVOA5fBQU=/?invite_link_id=308762229734
Writing a book about a modeling method (in our case: Domain Storytelling) necessarily makes you reflect on your own modeling practices. We had to frame things that we intuitively did in workshops. And we had to put our own approach into relation to other modeling methods. In this Meetup, we would like to talk about two concepts that came from these thoughts and discuss with you if they are applicable to collaborative modeling in general: Scope: Before a workshop, we try to figure out which kind of model is needed to make the workshop successful. This led to the concept of “scope”: Which point in time should we model? At which level of granularity should we model? Should we model the pure business process or how the software-supported process works? Scenario-based modeling: Several modeling methods that are popular with DDD practitioners are based on scenarios – meaning that one model shows only one case. Scenarios help a lot to learn and to deal with complexity. But they also raise the questions of which scenarios are relevant and how to keep an overview over many scenarios.
'It is not the domain experts knowledge that goes in production, it is the assumption of the developers that goes into production' This famous quote from Alberto Brandolini is unfortunately true but it also points to the right direction: we need to bring the domain knowledge into our software. This time one of our organisers Krisztina will show you how this can be done in the day to day business, she will share her experience including the list of techniques needed to succeed in having real Domain-driven development. This won't be a slide show, challenges, questions are welcome!
Our models should be driven by the domain, but not constrained by what domain experts tell us. After all, the domain language is messy, organic, ambiguous, social, incomplete, and if it has any intentional design to it at all, it's not designed to be turned into software. Modelling is more than capturing requirements, it's the opportunity to create novel concepts. This talk will use real-world stories to invite you to discuss.
In the last week of this year, we are closing another full year of virtual Domain-driven design meetups with the last meetup. So grab your drinks (tea, lemonade or anything you want!) and come join with your DDD questions to this lean coffee! We all post topics we want to discuss and together we will get into dialogues, so bring us your knowledge and DDD questions and see you then!
The term “sociotechnical” seems to have gotten a bit or renaissance lately, which is a great thing given all the positive impact it has had on many organisations and their workers around the world over the years. It also seems to have gotten some traction outside the academic circles this time after being developed and pushed from there mostly using action research since its humble beginning in the post-war British coal mines. It is an entry into systems thinking for many, with its idea about joint optimisation of both the technical and social aspects of an organisation. A common example is setting up the team topology to match the service architecture in an attempt to cater for negative effects of Conway’s law. This is all well and good, but if we think about it, viewing the modern organisation as a sociotechnical system is a bit of a tautology; all organisations have social and technical elements that people deal with on a daily basis. As with systems thinking, the value of sociotechnical system design is more about perspective and understanding rather than any specific outcome. There is so much more to sociotechnical design than DevOps and team setup that we need in order to cope in our increasingly complex and hazardous “digital coal mines.” Disclaimer: This talk is a prototype and is loosely based on my lightning talks at DDD Europe 2021 and DDD Europe Open Space, with the addition of new learning of Emery's Open Systems Theory as a foundation for sociotechnical systems design. Hope this will be more of a common exploration of the topics than a pure lecture. slides: https://www.dropbox.com/s/eeylt3cafssuogp/Open%20Sociotechnical%20Systems%20Thinking.pdf?dl=0
Most people introduced to Domain-Driven Design usually start with the first parts of the book, a very tactical approach treating DDD as a programming discipline. Then people begin discovering the architecture ideas in it, telling DDD is more than code. That is where they get introduced to the more strategic approach. But tactical vs strategic thinking can quickly turn into a polarity discussion where one is perceived as more important than the other. But with any polarity, both have up and down-side, you cannot do the one without the other. But when do we invest in one, and when into the other? Join us in this collaborative modelling session, where through dialogues we can discover signals when either strategy or tactical is not helpful anymore, and explore heuristics together to move to the other side, keeping the balance, doing tactical AND strategic design when we most need it!
DDD is probably one of the most important ecosystems of the last 20 years of software engineering. Nowadays frontend applications are an important piece of software architecture. Nevertheless, Bounded Contexts, Aggregates, Anticorruption Layers are all well-known concepts that somehow are often not applied when building large and complex frontend applications. The purpose of this talk is to show how some of the DDD techniques are easily applied to Frontend engineering, resulting in more robust and evolvable codebases.
'Begin with the end in mind' - Stephen Covey 70% of transformation efforts fail, and they fail because they lack clarity. 8 people will have 8 understandings of problems and solutions. By breaking down a target outcome, we create clarity and converge. Outcome Mapping is the first activity in Flow Engineering, which arose out of the need for clarity before starting further mapping activities. Outcome Mapping has its own flow, from ideas and pains to methods, guiding you from desire to action. You can map outcomes whether you are starting, in the middle or in the home stretch. It's a great way to bring a group together to converge, and set off in the right direction as a team. In this session: * Why outcome mapping is a critical activity * You'll see how outcome mapping works * How to create your own outcome map * Outcome mapping outcomes :] * I'll also share similar and complimentary techniques to provide many options for future exploration.ddddd