% Domain-Driven Design - Parts I, II % Javier Eduardo Rojas Romero % April, 2020 ## Part I ## Ubiquitous Language ### Ubiquitous Language The set of names, actions, and relationships used to model a system: * Spoken by everybody * Used everywhere ### One Team, One Language > Technical people often feel the need to "shield" the business experts from the > domain model... § . . . > If sophisticated domain experts don't understand the model, there is something > wrong with the model. ### Modeling Out Loud "If we give the **Routing Service** an origin, destination, and arrival time, it can look up the stops the cargo will have to make and, well ... stick them in the database." § . . . "The origin, destination, and so on ... it all feeds into the **Routing Service**, and we get back an **Itinerary** that has everything we need in it." § . . . "A **Routing Service** finds an **Itinerary** that satisfies a **Route Specification.**" ### Executable Bedrock > Well written code can be communicative, but the message it communicates is > not guaranteed to be accurate. > It takes fastidiousness to write code that doesn't just _do_ the right thing > but also _says_ the right thing. ## Binding Model and Implementation --- The model must guide the implementation ### Don't separate analysis/design and implementation * Crucial discoveries always emerge during the design/implementation effort * Very specific, unanticipated problems always arise ### Initial analyses * Go into depth about some irrelevant subjects * Overlooks some important subjects * Subjects might be represented in ways that are not useful to the application. ### Usual results * Results are abandoned soon after coding starts, and most of the ground has to be covered again * Design-while-implementing usually is rushed * Access to domain experts is difficult after implementation starts ### Model-Driven Design The design must: * Reflect the domain model in a very literal way * Must be naturally implemented in software Revisit/refactor/rethink until you get both ### Additional remarks * DDD is Object Oriented (expressive, mature) . . . * Aim is not to simplify concepts (let bones show) . . . * Software construction is _all_ about design . . . * The _model_ is meant to be _refactored_ ## Part II ## Layered Architecture --- ![](img/layers.png) ### User Interface :::::::::: {.columns} ::: {.column width="50%"} Shows information to the user Interprets user commands ::: ::: {.column width="50%"} ![](img/layers.png) ::: :::::::::: ### Application Layer :::::::::: {.columns} ::: {.column width="50%"} Provides functionalities via domain objects Thin, coordinates This is what "User Stories" are all about ::: ::: {.column width="50%"} ![](img/layers.png) ::: :::::::::: ### Domain Layer :::::::::: {.columns} ::: {.column width="50%"} It's the place for the business concepts, information, rules, etc. ::: ::: {.column width="50%"} ![](img/layers.png) ::: :::::::::: ### Infrastructure Layer :::::::::: {.columns} ::: {.column width="50%"} Provides _generic_ technical capabilities that support the higher layers. ::: ::: {.column width="50%"} ![](img/layers.png) ::: :::::::::: ## Modeling Materials --- :::::::::: {.columns} ::: {.column width="33%"} #### Base Elements [Entities]{.smallcaps} [Value Objects]{.smallcaps} [Associations]{.smallcaps} ::: ::: {.column width="33%"} #### Life Cycle [Aggregates]{.smallcaps} [Factories]{.smallcaps} [Repositories]{.smallcaps} ::: ::: {.column width="33%"} #### Complexity Handling [Services]{.smallcaps} [Modules]{.smallcaps} ::: :::::::::: ## Base Elements ### Entities Defined by their **identity**, not their attributes Match objects with different attribute values but same identity Are different from objects with the same attributes but different identity ### Value Objects Objects that describe things (what, not who) Only their values are relevant. Immutable*. They enable optimizations. ### Associations :::::::::: {.columns} ::: {.column width="50%"} ![](img/assoc-1.png) ::: ::: {.column width="50%"} ![](img/assoc-2.png) ::: :::::::::: ## Life Cycle ### Aggregates Boundaries between groups of one or more [Entities]{.smallcaps}/[Value Objects]{.smallcaps} ### Aggregates They have a **root Entity/Value Object**, and specify global/local scope for identities ![](img/aggregate-refs.png) ### Aggregates Define scope of invariants/constraints, and transactionality (atomic/eventual consistency) ![](img/aggregate-constraints.png) ### Factories Complex object creation belongs to the Domain layer But usually doesn't belong into any specific [Entity]{.smallcaps}/[Value Object]{.smallcaps}/ [Aggregate]{.smallcaps} Enter [Factories]{.smallcaps} ### Repositories They provide the "illusion of an in-memory collection of all objects" Provide access to **root objects** not easily reachable via [Associations]{.smallcaps} Abstract the specific storage technology used ## Complexity Handling ### Services :::::::::: {.columns} ::: {.column width="50%"} ![](img/services-1.png) ::: ::: {.column width="50%"} ![](img/services-2.png) ::: :::::::::: [Execution in the Kingdom of Nouns](https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) ### Services Don't tuck everything into services. Not-so-fat-models are OK. ### Modules > It is a truism that there should be _low coupling_ between > [Modules]{.smallcaps} and _high cohesion_ between them. ---- ![](img/say-what.jpg) ### Modules - Low Coupling > There is a limit to how many things a person can think about at once (hence > low coupling) ### Modules - High Cohesion > Incoherent fragments of ideas are as hard to understand as an undifferentiated > soup of ideas (hence high cohesion) ### Modules Complexity: intellectual unmanageability > Yet, it isn't just code being divided into [Modules]{.smallcaps}, but > concepts ## An Extended Example ---- ![](img/example-1.png){.stretch} ---- ![](img/example-2.png){.stretch} ---- ![](img/example-3.png){.stretch} ---- ![](img/example-4.png){.stretch} ---- ![](img/example-5.png){.stretch} ---- ![](img/example-6.png){.stretch}