Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Domain-Driven Design and Collab...

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.

Kenny Baas-Schwegler

September 12, 2024
Tweet

More Decks by Kenny Baas-Schwegler

Other Decks in Programming

Transcript

  1. @kenny_baas @[email protected] 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
  2. “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 @[email protected]
  3. 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 @[email protected]
  4. 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 @[email protected] 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.
  5. “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 @[email protected]
  6. “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 @[email protected]
  7. 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 @[email protected]
  8. @kenny_baas @[email protected] 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
  9. @kenny_baas @[email protected] 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
  10. Game of Telephone - 3 guys draw on each others

    back - Try to … YouTube @kenny_baas @[email protected] The need for collaborative modelling
  11. It is not the domain experts knowledge that goes to

    production, it is the assumption of the developers that goes to production @kenny_baas @[email protected] What goes to production — Alberto Brandolini, Creator of Eventstorming
  12. @kenny_baas @[email protected] 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.
  13. 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 @[email protected] Types of Eventstorming Alberto Brandolini - www.eventstorming.com
  14. 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 @[email protected] Types of Eventstorming Alberto Brandolini - www.eventstorming.com
  15. Time Cinderella lost her shoes Clock ticked 12 Prince found

    the shoe @kenny_baas @[email protected] 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
  16. @kenny_baas @[email protected] 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
  17. 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 @[email protected] Using it for Domain Modelling
  18. @kenny_baas @[email protected] There are many tools out there! Example mapping

    Core domain chats Context mapping and many more... Bounded context canvas
  19. @kenny_baas @[email protected] “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
  20. @kenny_baas @[email protected] 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.
  21. @kenny_baas @[email protected] 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 .....
  22. @kenny_baas @[email protected] 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
  23. @kenny_baas @[email protected] 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 .....
  24. 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 @[email protected] Teams and Bounded Context Bounded Context Bounded Context Application/Deployment Boundary Bounded Context Application/Deployment Boundary Stakeholders + Team
  25. @kenny_baas @[email protected] 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
  26. 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 @[email protected] Decompose & Distilling with Eventstorming Finding movies Selecting tickets
  27. @kenny_baas @[email protected] 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
  28. 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 @[email protected]
  29. 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 @[email protected] Domain-​ Driven Design
  30. @kenny_baas @[email protected] 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
  31. 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 @[email protected]
  32. @kenny_baas @[email protected] 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, ...)
  33. @kenny_baas @[email protected] Where to start? github.com Domain-Driven Design Crew Domain-Driven

    Design Crew has 14 repositories available. Follow their code on GitHub. Understand
  34. @kenny_baas @[email protected] From a team perspective github.com Domain-Driven Design Crew

    Domain-Driven Design Crew has 14 repositories available. Follow their code on GitHub.