DDD re-distilled

DDD re-distilled

An introduction to DDD strategic and tactical patterns.
Based on the work of the ddd-crew.

9489b8d6f2dbdc3e7d26b8702143b86e?s=128

Yoan

May 27, 2020
Tweet

Transcript

  1. 2.

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

    @yot88 REVERSE THE CONWAY’S LAW Structure your system into independent,

    self-contained services so that teams can work independently. 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. Build teams that look like the architecture you want : Cross functional teams organized around business capabilities
  3. 4.

    @yot88 DDD what ? Eric Evans – 2003 (foreword by

    Martin Fowler) Domain Driven Design : an approach to software development DDD is definitely NOT about technology. DDD is all about the domain. “This layer is the heart of business software.”
  4. 7.

    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
  5. 11.

    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
  6. 14.

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

    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
  8. 16.

    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.
  9. 19.

    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
  10. 21.

    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
  11. 22.

    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
  12. 23.

    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.
  13. 26.

    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
  14. 28.

    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.
  15. 34.

    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 wants to see Z, in order to …” In / Out messages Clear contracts
  16. 38.
  17. 40.

    TACTICAL PATTERNS Data access Underlying persistence ignorant Handle object creation

    Define business invariants + boundaries I : Immutable data structure I I Class types
  18. 41.

    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
  19. 42.

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

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

    @yot88 Design small aggregates Memory footprint and transactional scope of

    each Aggregate should be relatively small. Apply SRP
  22. 45.

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

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

    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
  25. 50.

    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.
  26. 51.

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

    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 ?
  28. 53.

    @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
  29. 54.
  30. 55.

    To go further CQRS Hexagonal architecture Micro-services Event sourcing Actor

    model Conway’s law Functional Core Team topologies