Introduction to Domain-Driven Design and Collaborative software design

Are you eager to create software that meets both user and stakeholder needs while achieving business goals? Do you want to design and architect software that remains adaptable and resilient as your business grows? Curious about how your team can take ownership of designing software for user needs? In this talk, I will introduce you to Domain-Driven Design (DDD) in simple terms, explaining what DDD is, when it’s useful, and when it’s not.

We’ll discuss the differences between tactical and strategic design and why balancing both is essential for staying adaptable. I'll provide examples to show why focusing only on tactical design, like writing code with aggregates, or only on strategic design, like context mapping and bounded context design, can cause issues. Instead, I’ll show that the key to successful software design is maintaining an ongoing dialogue with stakeholders like users and domain experts and collaborating on the design process. A valuable technique for this ongoing dialogue is collaborative modelling. In this meetup, I will demonstrate the collaborative modelling tool EventStorming and show you how it can help maintain that ongoing dialogue. You will leave understanding what DDD is and why collaborative software design is important for building adaptable and resilient software.

Transcript

1. Introduction to Domain-​ Driven Design and Collaborative software design @kenny_baas @kenny_baas@mastodon.social
2. @kenny_baas @kenny_baas@mastodon.social Big Ball of MUD Microservices How is your current architecture? Drag one dot per person from below into one of the squares on the right to answer the question. Monolith Distributed Monolith
3. Monolithic Application Database Trading engineering Team Personal Finance Engineering Team INTERDEPENDENT TEAMS Somewhere around the Millennium @kenny_baas @kenny_baas@mastodon.social
4. “If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.” — Eric Evans, Domain-​ Driven Design: Tackling Complexity in the Heart of Software Software Design @kenny_baas @kenny_baas@mastodon.social
5. Questions about whether design is necessary or affordable are quite beside the point: Design is inevitable. The alternative to good design is bad design, not no design at all. — Douglas Martin There is always a design! @kenny_baas @kenny_baas@mastodon.social
6. Whatever time the team members spend re-​establishing a common view of the universe is the incoherence penalty. By Ruth Malan Incoherence Penalty @kenny_baas @kenny_baas@mastodon.social www.michaelnygard.com Coherence Penalty for Humans - Wide Awake Developers This is a brief aside from my ongoing series about avoiding entity services. An interesting dinner conversation led to thoughts that I needed to write down. Amdahl's Law In 1967, Gene Amdahl presented a case against multiprocessing computers.
7. “To communicate effectively, the code must be based on the same language used to write the requirements—​ the same language that the developers speak with each other and with domain experts.” Communicate effectively — Eric Evans, Domain-​ Driven Design: Tackling Complexity in the Heart of Software @kenny_baas @kenny_baas@mastodon.social
8. “A language structured around the domain model and used by all team members to connect all the activities of the team with the software.” Ubiquitous Language — Eric Evans, Domain-​ Driven Design: Tackling Complexity in the Heart of Software @kenny_baas @kenny_baas@mastodon.social
9. What is wrong about this map? @kenny_baas @kenny_baas@mastodon.social
10. Another map, another model @kenny_baas @kenny_baas@mastodon.social
11. Mercator Solving a specific problem @kenny_baas @kenny_baas@mastodon.social
12. A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind. — Rebecca Wirfs-​ Brock A model is.... @kenny_baas @kenny_baas@mastodon.social
13. @kenny_baas @kenny_baas@mastodon.social Photo by Agnieszka Ziomek on Unsplash How do you Discover business problem? business problems: the various needs of our users and stakeholders. Stakeholders are individuals or groups, either within or outside the organization, who are invested in the outcome of solving these business problems. Their needs can range from overarching purposes and objectives to specific goals, tasks, customer and user journeys, business processes, constraints, and any challenges they face. Specific use in solving Business problems
14. @kenny_baas @kenny_baas@mastodon.social indiyoung.com X Explanations Problem Space The problem space is a person's domain. It's where they are addressing something they want to make progress on, or put off, or just think about. The problem space is separate from your solutions, although the person may reach out for your tool along the… https://indiyoung.com/explanations-​ problem-​ space/ 💡Software design starts HERE However stream-​ aligned teams are usually involved somewhere here
15. Game of Telephone - 3 guys draw on each others back - Try to … YouTube @kenny_baas @kenny_baas@mastodon.social The need for collaborative modelling
16. It is not the domain experts knowledge that goes to production, it is the assumption of the developers that goes to production @kenny_baas @kenny_baas@mastodon.social What goes to production — Alberto Brandolini, Creator of Eventstorming
17. @kenny_baas @kenny_baas@mastodon.social Collaborative modelling is a visualisation technique to analyse complex and conflict-​ laden decision-​ making processes with all relevant stakeholders and decision-​ makers to create a shared understanding.
18. Big Picture Process modelling Software Design Model and discover an entire business line: As-​ Is 15-70 people Common understanding between domain experts; massive learning Trigger long-​ awaited conversations Reach a consensus on what the core problem is Disagreements are okay Doing the right thing: As-​ Is 5-10 people Scope: epic / set of features Product owner absolutely required! Value proposition, policies, personas Consensus must be reached Doing the thing right: To-​ Be Consensus must be reached Every hotspot should be addressed @kenny_baas @kenny_baas@mastodon.social Types of Eventstorming Alberto Brandolini - www.eventstorming.com
19. As-​is To-​be 30000 feet Enterprise/Domain Scope 10000 feet Domain to Application Scope Team Application scope Big Picture Process modelling Software design @kenny_baas @kenny_baas@mastodon.social Types of Eventstorming Alberto Brandolini - www.eventstorming.com
20. Time Cinderella lost her shoes Clock ticked 12 Prince found the shoe @kenny_baas @kenny_baas@mastodon.social What do we need? Alberto Brandolini - www.eventstorming.com Step sister cut of her toe's This is the brother grimms story. Which one are we modlling
21. @kenny_baas @kenny_baas@mastodon.social Photo by Agnieszka Ziomek on Unsplash seats are reserved Film got selected Discount got applied tickets are delivered seats are locked # of tickets selected Tickets are paid Is this the same or not? 1 reservation per seat cancellation policy: after 15 minutes not payed seats got cancelled Reserve seats - reserved seats - countdown times - Free seats movie visitor Change seats
22. Domain is a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. An area of interest or an area over which a person has control It is all about grouping concepts. Within Domain-​ Driven Design we call the entire problem space we are modelling the Domain. We decompose that space into several subdomains. If the space is big enough those subdomains can be potentially split into several subdomains again. @kenny_baas @kenny_baas@mastodon.social Using it for Domain Modelling
23. @kenny_baas @kenny_baas@mastodon.social Use collaborative modelling to create a shared understanding
24. @kenny_baas @kenny_baas@mastodon.social There are many tools out there! Example mapping Core domain chats Context mapping and many more... Bounded context canvas
25. @kenny_baas @kenny_baas@mastodon.social “To communicate effectively, the code must be based on the same language used to write the requirements—​ the same language that the developers speak with each other and with domain experts.” — Eric Evans, Domain-​ Driven Design: Tackling Complexity in the Heart of Software Communicate effectively
26. @kenny_baas @kenny_baas@mastodon.social What do we mean with...? https://www.huffingtonpost.co.uk/entry/american-​ tweets-​ about-​ great-​ british-​ bake-​ off_uk_61733eaee4b03072d6f6d012
27. @kenny_baas @kenny_baas@mastodon.social Ambiguity
28. @kenny_baas @kenny_baas@mastodon.social What do we mean with...? We all know or should know that language is fluid, liquid, subject to the whims of the people. Language evolves, as it should. Because language changes to accommodate new users, the older users resist and complain.
29. @kenny_baas @kenny_baas@mastodon.social Bounded Context is a language boundary Users and stakeholders Code Stream-​ Aligned Team Tests Other people possibly involved in designing and building software Managers Architects User researcher .....
30. @kenny_baas @kenny_baas@mastodon.social A model is... A model is a simplified representation of a thing or phenomenon that intentionally emphasizes certain aspects while ignoring others. Abstraction with a specific use in mind. — Rebecca Wirfs-​ Brock
31. @kenny_baas @kenny_baas@mastodon.social Bounded Context Users and stakeholders Code Stream-​Aligned Team Tests Domain Model Other people possibly involved in designing and building software Managers Architects User researcher .....
32. Stakeholders + Team Stakeholders + Team Application/Deployment Boundary Bounded Context Bounded Context Bounded Context Application/Deployment Boundary Bounded Context Application/Deployment Boundary Application/Deployment Boundary Communication Communication Strategic monoliths Self contained systems & Microservices architecture 1 bounded context = 1 Team 1 Team can have multiple bounded context * Disclaimer: People disagree about the naming. @kenny_baas @kenny_baas@mastodon.social Teams and Bounded Context Bounded Context Bounded Context Application/Deployment Boundary Bounded Context Application/Deployment Boundary Stakeholders + Team
33. @kenny_baas @kenny_baas@mastodon.social The domain model “The domain model will typically derive from the domain experts’ own jargon but will have been “cleaned up,” to have sharper, narrower definitions.” — Eric Evans, Domain-​ Driven Design: Tackling Complexity in the Heart of Software
34. Seats Reserved Tickets Received Payment Completed Ticket sold Movie selected 4 normal pricing selected Total price calculated Seat reservation suggested View time selected Payment details provided Seats moved Seats confirmed 4 friends want to watch the new Marvel movie Website opened Country selected Language selected Theater picked Date picked Domain event Legend @kenny_baas @kenny_baas@mastodon.social Decompose & Distilling with Eventstorming Finding movies Selecting tickets
35. @kenny_baas @kenny_baas@mastodon.social Find the natural boundaries
36. @kenny_baas @kenny_baas@mastodon.social Pick some boundaries and iterate
37. @kenny_baas @kenny_baas@mastodon.social Pick some boundaries and iterate
38. @kenny_baas @kenny_baas@mastodon.social Pick some boundaries and iterate
39. @kenny_baas @kenny_baas@mastodon.social Bounded Context Canvas Seat allocations Optimise allocations for customers and make sure the room is filled up as much as possible Planning Allocate places Movie time Planned Movie Screening Ticket Booth Allocation A C L A C L Allocation is confirmed A C L 1 place should only have 1 reservation allocated Can only confirm places that are allocated to the reservation Free up allocated seats from previous allocation Free up allocated seats when changing allocation An allocation can only contain places adjacent on 1 row
40. Using models for creating software with DDD tactical patterns The models and the team have relationships which we assess/overview with DDD Strategic patterns A pattern language @kenny_baas @kenny_baas@mastodon.social
41. Collaborative Modelling Tactical Patterns Strategic Patterns 3 pillars of DDD @kenny_baas @kenny_baas@mastodon.social
42. DDD is a discipline rooted in the belief that creating good software systems for problems in the complex domain cannot be done without a deep understanding of the business problems you are trying to solve in the domain. @kenny_baas @kenny_baas@mastodon.social Domain-​ Driven Design
43. @kenny_baas @kenny_baas@mastodon.social We share context, meaning and categorise business needs, purpose and problems. Through that we DESIGN a language and model to solve complex business problems Photo by Travel by Kilts
44. It has a set of principles for designing software to guide that belief and a lot of patterns, tools and techniques that enable us to follow these principles. The principles are as followed: In order to create a software system for a complex domain, there needs to be a deep, shared understanding of the domain itself by all stakeholders involved. Creating that shared understanding is guided by the domain experts. To improve understanding, the stakeholders communicate with each other in a language, the Ubiquitous Language, which is crafted from the domain language. Unlike the domain language, the ubiquitous language is unambiguous. The shared understanding is expressed in a model, which uses the ubiquitous language, and captures the complexity of the domain inside the problem space. The system has explicit boundaries, called bounded contexts, in which the model and ubiquitous language are consistent. Stakeholders should continuously improve their understanding and refactor the model towards deeper insight. Set of principles @kenny_baas @kenny_baas@mastodon.social
45. @kenny_baas @kenny_baas@mastodon.social Domain-​ Driven Design presents an all-​ encompassing view on software design. It considers design from the micro-​ level of code and design patterns, to models and their language, to communication and relationships between models, to the large scale reasoning about systems of systems. On top of that, it aims to be pragmatic. You don’t apply DDD everywhere, you do it where it will have the most impact. DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. Many methods that people now consider core to DDD, such as EventStorming, didn’t exist when the book was written. Important Notes verraes.net What is Domain-Driven Design (DDD) Domain-Driven Design is a software design discipline centred on the principles that: Software for a complex domain requires all designers (engineers, testers, analysts, ...)
46. @kenny_baas @kenny_baas@mastodon.social Where to start? github.com Domain-Driven Design Crew Domain-Driven Design Crew has 14 repositories available. Follow their code on GitHub. Understand
47. @kenny_baas @kenny_baas@mastodon.social From a team perspective github.com Domain-Driven Design Crew Domain-Driven Design Crew has 14 repositories available. Follow their code on GitHub.
48. @selketjah @kenny_baas @EvelynvanKelle @kenny_baas @kenny_baas@mastodon.social
49. @kenny_baas @kenny_baas@mastodon.social Thank You #CatTax kenny@weave-​ it.org - weave-​ it.org Get the book here
50. @kenny_baas @kenny_baas@mastodon.social https://amplitude.com/blog/journey-​ to-​ product-​ teams-​ infographic AKA blockers to flow