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
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
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.”
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
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
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.
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
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
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
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.
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
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
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.
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.
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
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
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
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.
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.
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.
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
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 ?
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
yasslab
n0bisuke2
masaru_b_cl
harukahosokawa
mabokaneko0802
tosseto
ksatirli
awsjcpm
ramtop
zilmina
pokotyamu
develop_neoguri
addyosmani
samlambert
sugarenia
sferik
kastner
eileencodes
mclloyd
kneath
honnibal
mongodb
aleyda
keithpitt
