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 @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
  2. Monolithic Application Database Trading engineering Team Personal Finance Engineering Team

    INTERDEPENDENT TEAMS Somewhere around the Millennium @kenny_baas @kenny_baas@mastodon.social
  3. “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
  4. 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
  5. 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.
  6. “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
  7. “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
  8. 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
  9. @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
  10. @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
  11. Game of Telephone - 3 guys draw on each others

    back - Try to … YouTube @kenny_baas @kenny_baas@mastodon.social The need for collaborative modelling
  12. 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
  13. @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.
  14. 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
  15. 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
  16. 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
  17. @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
  18. 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
  19. @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
  20. @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
  21. @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.
  22. @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 .....
  23. @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
  24. @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 .....
  25. 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
  26. @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
  27. 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
  28. @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
  29. 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
  30. 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
  31. @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
  32. 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
  33. @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, ...)
  34. @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
  35. @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.