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
@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
@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.”
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
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
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
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
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.
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
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
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
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.
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
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
TACTICAL PATTERNS Data access Underlying persistence ignorant Handle object creation Define business invariants + boundaries I : Immutable data structure I I Class types
@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
@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.
@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.
@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
@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
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
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.
@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.
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.
@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
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 ?
@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
thirion
akatsuki174
kaga
melix
ma2shita
runrunsan
n0bisuke2
harunakano
takunology
bigtree
gr2m
mthomps
stephaniewalter
kevinliebholz
thoeni
lauravandoore
denniskardys
hatefulcrawdad
sstephenson
eileencodes
productmarketing
orderedlist