Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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]

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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]

Slide 13

Slide 13 text

@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

Slide 14

Slide 14 text

@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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

@kenny_baas @[email protected] Ambiguity

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

@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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

@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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

@kenny_baas @[email protected] Find the natural boundaries

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

@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

Slide 40

Slide 40 text

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]

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

@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

Slide 44

Slide 44 text

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]

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

@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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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