Introduction to Domain-​ Driven Design and Collaborative software design @kenny_baas @[email protected]

@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

Monolithic Application Database Trading engineering Team Personal Finance Engineering Team INTERDEPENDENT TEAMS Somewhere around the Millennium @kenny_baas @[email protected]

“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]

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]

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.

“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]

“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]

What is wrong about this map? @kenny_baas @[email protected]

Another map, another model @kenny_baas @[email protected]

Mercator Solving a specific problem @kenny_baas @[email protected]

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]

@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

@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

Game of Telephone - 3 guys draw on each others back - Try to … YouTube @kenny_baas @[email protected] The need for collaborative modelling

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

@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.

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

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

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

@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

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

@kenny_baas @[email protected] Use collaborative modelling to create a shared understanding

@kenny_baas @[email protected] There are many tools out there! Example mapping Core domain chats Context mapping and many more... Bounded context canvas

@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

@kenny_baas @[email protected] What do we mean with...? https://www.huffingtonpost.co.uk/entry/american-​ tweets-​ about-​ great-​ british-​ bake-​ off_uk_61733eaee4b03072d6f6d012

@kenny_baas @[email protected] Ambiguity

@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.

@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 .....

@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

@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 .....

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

@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

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

@kenny_baas @[email protected] Find the natural boundaries

@kenny_baas @[email protected] Pick some boundaries and iterate

@kenny_baas @[email protected] Pick some boundaries and iterate

@kenny_baas @[email protected] Pick some boundaries and iterate

@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

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]

Collaborative Modelling Tactical Patterns Strategic Patterns 3 pillars of DDD @kenny_baas @[email protected]

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

@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

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]

@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, ...)

@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

@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.

@selketjah @kenny_baas @EvelynvanKelle @kenny_baas @[email protected]

@kenny_baas @[email protected] Thank You #CatTax kenny@weave-​ it.org - weave-​ it.org Get the book here

@kenny_baas @[email protected] https://amplitude.com/blog/journey-​ to-​ product-​ teams-​ infographic AKA blockers to flow