Slide 1

Slide 1 text

@yot88 By yoan thirion DDD RE-DISTILLED

Slide 2

Slide 2 text

Who am I ? Technical Agile coach, Software craftsman I’m Yoan THIRION (freelance) • design software since more than 12 years • fundamental to succeed in that area : agility and technical excellence • help teams deliver well crafted software • implementation of agile and technical practices (eXtreme programming, Refactoring, DDD, Mob programming, …) Let’s connect My services https://www.yoan-thirion.com/ Technical agile coaching Communities of practice Cultural change devops Brown bags Serious games

Slide 3

Slide 3 text

@yot88 CONWAY’S LAW “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” - Melvin Conway Style of code reflect the way the people and teams in your company communicate or produce software architectures matching their current structure can lead to OUTDATED AND LOWER QUALITY PRODUCTS

Slide 4

Slide 4 text

@yot88 DDD what ? Domain Driven Design : an approach to software development Eric Evans – 2003 (foreword by Martin Fowler) DDD is NOT about technology. DDD is all about the domain. “This layer is the heart of business software.”

Slide 5

Slide 5 text

DDD distilled

Slide 6

Slide 6 text

PATTERNS TACTICAL STRATEGIC

Slide 7

Slide 7 text

Start with a strategy Not a tactic TACTICAL PATTERNS Data access Underlying persistence ignorant Handle object creation Define business invariants + boundaries I : Immutable data structure I I Class types

Slide 8

Slide 8 text

@yot88 START WITH A STRATEGY

Slide 9

Slide 9 text

STRATEGIC PATTERNS

Slide 10

Slide 10 text

@yot88 DOMAIN MODEL Problem Space solution Space

Slide 11

Slide 11 text

BOUNDED CONTEXTS A Bounded Context is a semantic contextual boundary. Within the boundary each component of the software model has a specific meaning and does specific things. Software model = language that is developed by the team Spoken by every member of the team Implemented in the software model This language = Ubiquitous Language

Slide 12

Slide 12 text

BOUNDED CONTEXTS Focus on Business Complexity, Not Technical Complexity “What is core?” Challenge and unify!

Slide 13

Slide 13 text

BOUNDED CONTEXTS Emerge from workshops Express Core Domain as a set of concrete scenarios

Slide 14

Slide 14 text

BOUNDED CONTEXTS There should be : One team assigned to work on one Bounded Context A separate source code repository for each Bounded Context One team could work on multiple Bounded Contexts BUT multiple teams should not work on a single Bounded Context

Slide 15

Slide 15 text

SUBDOMAINS 1 of the Bounded Contexts will be the Core Domain Various Subdomains in other Bounded Contexts A Bounded Context should align one-to-one (1:1) with a single Subdomain

Slide 16

Slide 16 text

3 Types of Subdomains Solution may be available for purchase or be outsourced or even developed in house by a team that doesn’t have the kind of elite developers that you assign to your Core Domain or even a lesser Supporting Subdomain. NO WAY TO DIFFERENTIATE Where you are making a strategic investment in a single, well-defined domain model. This is very high on your organization’s list of projects because it will distinguish it from all competitors. The heart of an organization’s business This is a modeling situation that calls for custom development, because an off-the-shelf solution doesn’t exist. This is still an important software model, because your Core Domain cannot be successful without it.

Slide 17

Slide 17 text

CONTEXT DISTILLATION https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5 https://github.com/ddd-crew/core-domain-charts

Slide 18

Slide 18 text

TEAM TOPOLOGIES https://youtu.be/8TDiuQ3vdh0 https://speakerdeck.com/mploed/visualizing-sociotechnical-architectures-with-context-maps

Slide 19

Slide 19 text

CONTEXT MAPPING Integration between Core Domain and other Bounded Contexts is known in DDD as Context Mapping. Considering that in two different Bounded Contexts there are two Ubiquitous Languages , this line represents the translation that exists between the two languages

Slide 20

Slide 20 text

CONTEXT MAPPING Which kind of relationships and integrations can be represented by the Context Mapping line?

Slide 21

Slide 21 text

CONTEXT MAPPING What relationships and integrations can be represented by the Context Mapping line? PARTNERSHIP A Partnership relationship exists between two teams. Each team is responsible for one Bounded Context. They create a Partnership to align the two teams with a dependent set of goals. It is said that the two teams will succeed or fail together. Teams will meet frequently to : • Synchronize schedules and dependent work • Use continuous integration to keep their integrations in harmony. The synchronization is represented by the thick mapping line between the two teams. The thick line indicates the level of commitment required, which is quite high. CUSTOMER-SUPPLIER Describes a relationship between two Bounded Contexts and respective teams : the Supplier is upstream (the U in the diagram) and the Customer is downstream (the D in the diagram). The Supplier holds sway in this relationship because it must provide what the Customer needs. • Downstream requirements factor into upstream planning. • Downstream team gains some influence over the priorities and tasks of the upstream team SUPPLIER CUSTOMER SHARED KERNEL A Shared Kernel , is a subset of a domain model that two teams share : • Physically shared artifact between two teams (Shared JARs, DB, …) • High degree of coupling requires a high amount of coordination between the involved teams Use it with caution https://www.youtube.com/watch?v=8TDiuQ3vdh0&feature=youtu.be

Slide 22

Slide 22 text

CONTEXT MAPPING CONFORMIST The conformist slavishly adheres to the upstream model : • No model-to-model transformation • Motivation : simplicity, contracts • The team implementing a Conformist is always downstream Example: Consider the need to conform to the Amazon.com model when integrating as one of Amazon’s affiliate sellers. ANTICORRUPTION LAYER The Anticorruption Layer translates one model to another one : (Looser coupling) • Transforms an external model from another team / bounded context / system to another internal one • Reduces the amount of coupling to a single layer • The team implementing the ACL is always downstream OPEN-HOST SERVICE Defines a protocol or interface that gives access to your Bounded Context as a set of services. The Open-host Service is a public API : • One API for several consumers • Has a common/general purpose model and functionality • The team providing the Service is an upstream team

Slide 23

Slide 23 text

CONTEXT MAPPING PUBLISHED LANGUAGE A well documented language shared between bounded contexts : • Every bounded context can translate in and out from that language • Often combined with Open-host Service Such a Published Language can be defined with XML Schema, JSON Schema, … Examples: iCalendar, vCard SEPARATE WAYS A bounded context has no connections to others : • Sometimes integration is too expensive or takes very long • The teams choose separate ways in order to focus on specialized solutions Perhaps the functionality that you seek is not fully provided by any one Ubiquitous Language. In this case produce your own specialized solution in your Bounded Context and forget integrating for this special case. BIG BALL OF MUD Here’s what happens over time when you are responsible for creating a Big Ball of Mud: (1) A growing number of Aggregates cross-contaminate because of unwarranted connections and dependencies. (2) Maintaining one part of the Big Ball of Mud causes ripples across the model, which leads to “whack-a-mole” issues. (3) Only tribal knowledge and heroics—speaking all languages at once—save the system from complete collapse.

Slide 24

Slide 24 text

CONTEXT MAPPING https://github.com/ddd-crew/context-mapping

Slide 25

Slide 25 text

CONTEXT MAPPING

Slide 26

Slide 26 text

@yot88 HOW TO DISCOVER COMPLEX DOMAINS ?

Slide 27

Slide 27 text

@yot88 EVENT STORMING : explore with Domain Events

Slide 28

Slide 28 text

@yot88 BIG PICTURE

Slide 29

Slide 29 text

@yot88 THE PICTURE that explains everything

Slide 30

Slide 30 text

@yot88 3 LEVELS

Slide 31

Slide 31 text

https://miro.com/app/board/o9J_ksetago=/ Use facilitation tricks

Slide 32

Slide 32 text

https://miro.com/app/board/o9J_ksetago=/ Use facilitation tricks

Slide 33

Slide 33 text

Use facilitation tricks Pivotal Events are specific events which are particularly relevant for the business and mark a transition between different business phases. Pivotal events Swim lanes Separating the whole flow into horizontal swimlanes, assigned to given actors or departments, is an option since to improve readability Temporal milestones Time might be a better splitter than events in some cases. Key / Pivotal Events or Temporal Milestones. https://leanpub.com/introducing_eventstorming

Slide 34

Slide 34 text

VOICES AGAINST EVENT STORMING “ALL THIS TIMES ONLY FOR POST-ITS ON A WALL” “WE WERE ALREADY ALIGNED”

Slide 35

Slide 35 text

CAPTURE OUTCOMES https://philippe.bourgau.net/5-views-to-capture-the-outputs-of-an-event-storming-workshop/ Next Actions Captured domain definition Shared understanding Decisions record Context map User stories “When user X does Y, he/she wants to see Z, in order to …” In / Out messages Clear contracts

Slide 36

Slide 36 text

Document your BOUNDED CONTEXTS Bounded Context Canvas https://medium.com/nick-tune-tech-strategy-blog/modelling-bounded-contexts-with-the-bounded-context-design-canvas-a-workshop-recipe-1f123e592ab https://github.com/ddd-crew/bounded-context-canvas

Slide 37

Slide 37 text

Document your BOUNDED CONTEXTS v3 Static HTML https://github.com/ddd-crew

Slide 38

Slide 38 text

@yot88 USE TACTICS

Slide 39

Slide 39 text

TACTICAL PATTERNS Data access Underlying persistence ignorant Handle object creation Define business invariants + boundaries I : Immutable data structure I I Class types

Slide 40

Slide 40 text

@yot88 Tactical Design with AGGREGATES Entity An Entity models an individual thing. Each Entity has a unique identity in that you can distinguish its individuality from among all other Entities of the same or a different type. Most times, an Entity will be mutable; its state will change over time. Value Object / Value Models an immutable conceptual whole. Unlike an Entity , it does not have a unique identity, and equivalence is determined by comparing the attributes encapsulated by the Value type. Aggregate Each Aggregate is composed of one or more Entities / Value Objects One Entity is called the Aggregate Root Each Aggregate forms a transactional consistency boundary : all composed parts must be consistent, according to business rules, when the controlling transaction is committed to the database

Slide 41

Slide 41 text

@yot88 AGGREGATE : RULES OF THUMBS Let’s next consider the four basic rules of Aggregate design: 1. Protect business invariants inside Aggregate boundaries. 2. Design small Aggregates. 3. Reference other Aggregates by identity only. 4. Update other Aggregates using eventual consistency.

Slide 42

Slide 42 text

@yot88 Protect business invariants inside Aggregate boundaries “When all Task instances have hoursRemaining of zero, the BacklogItem status must be set to DONE .” At the end of a transaction this very specific business invariant must be met. The business requires it.

Slide 43

Slide 43 text

@yot88 Design small aggregates Memory footprint and transactional scope of each Aggregate should be relatively small. Apply SRP

Slide 44

Slide 44 text

@yot88 Reference Other Aggregates by Identity Only Keep the Aggregate design small and efficient making for lower memory requirements quicker loading from a persistence store. Helps enforce the rule not to modify other Aggregate instances within the same transaction Store hem as you want Relational Database or not

Slide 45

Slide 45 text

@yot88 Update Other Aggregates Using Eventual Consistency A BacklogItem is committed to a Sprint : BacklogItem + Sprint must react to this As part of the BacklogItem Aggregate ’s transaction, it publishes a Domain Event At one point our system will be consistent

Slide 46

Slide 46 text

FROM Event Storming to Aggregates Aggregate Canvas https://www.youtube.com/watch?v=AF880t1RUU4

Slide 47

Slide 47 text

FROM Event Storming to Aggregates https://github.com/ddd-crew/aggregate-design-canvas

Slide 48

Slide 48 text

BOUNDED CONTEXTS & μSERVICES Agile Project Management ms 1 Bounded context 1 Micro-service Product-ms BacklogItem-ms Release-ms Sprint-ms Agile Project Management Bounded context VS Same semantic boundary

Slide 49

Slide 49 text

@yot88 A few words on Domain events

Slide 50

Slide 50 text

DOMAIN EVENTS Which content in our Domain Events ? The identity of the Policy -> policyId Any components in a subscribing Bounded Context would retain that identity If there is a need for more data than the PolicyIssued Domain Event provided Subscribing Bounded Context can query back on the Underwriting Context for more information Subscribing Bounded Context Subscribing Bounded Context

Slide 51

Slide 51 text

ENRICHMENT VS QUERY-BACK TRADE-OFFS Design thin Domain Events and a rich query model with security for consumers to request ENRICHMENT Enriching Domain Events with enough data to satisfy the needs of all consumers QUERY-BACK Thin Domain Events allowing querying back when consumers need more data Greater autonomy of dependent consumers Difficult to predict every piece of data that all consumers will ever need in Domain Events Could be poor security choice to greatly enrich Domain Events If autonomy is your driving requirement => Consider enrichment Sometimes circumstances will call for a balanced blend of both approaches.

Slide 52

Slide 52 text

REACTIVE DDD https://www.infoq.com/articles/modeling-uncertainty-reactive-ddd/ Defense Mechanisms De-Duplicator (evts 1,2,1,3 -> evts 1,2,3) Re-Sequencer Process manager

Slide 53

Slide 53 text

@yot88 WHAT COULD WE DO WITH THAT ?

Slide 54

Slide 54 text

@yot88 REVERSE THE CONWAY’S LAW Build teams that look like the architecture you want : Cross functional teams organized around business capabilities Microservices architectures aim to increase velocity, so they apply Conway’s law in reverse to structure the system to achieve this noble goal. Reverse Logic follows to create fewer dependencies and can grow faster as compared to Conway Law. Teams only focus on what they are building and how they communicate with other pieces of code or microservices.

Slide 55

Slide 55 text

Business Capability Map & DDD BUSINESS CAPABILITY MAP CONTEXT MAPPING The expression or the articulation of the capacity, materials, and expertise an organization needs in order to perform core functions A tool that allows you to identify the relationship between business domains and the relationship between the teams that are responsible for them.

Slide 56

Slide 56 text

@yot88 BUSINESS CAPABILITY MAP CONTEXT MAP • Encapsulate what a business is doing right now and what needs to be done to meet current and future challenges. • Define “what” a business does, rather than “how” it does it • Provide a common basis for discussion and planning • A clear link from strategy to execution • Involve the appropriate stakeholders that define the strategy • Carry out highly organized mergers & acquisitions • Accurately define roles within the business • Defined Ubiquitous languages, Models • Clear business / technical vision • Helps identify where to invest with DDD through strategic patterns • Global view on the system on contexts and their relationships • Help to clarify team interactions and responsibilities • Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared Business Capability Map & DDD CAN BE COMPLEMENTARY

Slide 57

Slide 57 text

Impact Mapping The Business Model Canvas The Product Strategy Canvas Wardley Mapping https://github.com/ddd-crew/ddd-starter-modelling-process/blob/master/README.md Domain Storytelling Example Mapping EventStorming User Journey Mapping Business Capability Modelling Design Heuristics EventStorming with sub-domains Independent Service Heuristics Visualising Sociotechnical Architecture with Context Maps Business Process Model and Notation Domain Message Flow Modelling Process Modelling EventStorming Sequence Diagrams Core Domain Charts Purpose Alignment Model Wardley Mapping Dynamic Reteaming Pioneers, Settlers & Town Planners Team Topologies Visualising Sociotechnical Architecture with Context Maps Bounded Context Canvas C4 System Context Diagram Quality Storming Aggregate Design Canvas C4 Component Diagrams Design-Level EventStorming Event Modelling Hexagonal Architecture Mob Programming Model Exploration Whirlpool Onion Architecture Unified Modelling Language A PROCESS TO EXPERIMENT ?

Slide 58

Slide 58 text

@yot88 KEY TAKE AWAYS

Slide 59

Slide 59 text

@yot88 KEY TAKE AWAYS DDD is a : Strategic tool that can help you Invest through Context Distillation Organize teams through Context Mapping Align everyone on a business / technical vision Design tool through Bounded Contexts Implementation tool through Tactical patterns

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

https://miro.com/miroverse/category/strategy-and-planning/strategic-domain-driven-design-template/

Slide 62

Slide 62 text

To go further CQRS Hexagonal architecture Micro-services Event sourcing Actor model Conway’s law Functional Core Team topologies

Slide 63

Slide 63 text

@yot88 Resources

Slide 64

Slide 64 text

@yot88 Resources DDD Tools • Github : DDD Crew • DDD Starter Modelling Process • Heuristics Articles • Domain Events vs Change Data Capture • Legacy Architecture Modernisation With Strategic Domain-Driven Design • Capture Event Storming Outputs • Visualizing sociotechnical architectures with context maps Templates • Strategic DDD miro template • Remote Context Mapping Miro Template • Event Storming Modelling tricks Videos • Context Mapping Practically applied • From Event Storming to Aggregates Conferences / Meetups • DDDEurope • Virtual DDD • Virtual DDD Meetup