Domain Driven Design (DDD)
Domain Driven Design
- Strategic Design (Overview of the domain/app on the higher level)
- Tactical Design (Overview at the lower level)
Strategic Design
We talk about the problems and not solutions yet.
- Event storming
- events
- commands
- policies, users
- Ubiquitous language
- Domain analysis -> Core subdomains -> Supporting subdomains -> Generic Subdomains
Core Subdomains The place where the business gets the most of the value. Code in this subdomain is written by developers.
Supporting Subdomains
- use off the shelf providers (payments, etc)
Generic Subdomains
- Outsourced, SAP, etc
Technical Design
Solution space, more technical
- Bounded contexts
- Very similar to subdomains but can span over multiple subdomains
- Entities
- Can span over multiple bounded contexts
- Value objects
- Aggregates
- Domain events
- Domain & Application services
Entities
- Unique Items, with a unique identifier. Example: A company with a unique ID
- May span multiple bounded contexts
Value Object
- have no ID, defined by its values
- immutable
- basic building blocks of the domain model. Example: status, address, etc
Aggregates
- Cluster one or more entities into a consistency boundary
- Has one root entity
- usually bound to a transaction scope
- Application service -> Domain service -> Aggregate -> root entity -> Entities & Value objects

Services
- Has no state
- Domain services encapsulate domain logic
- Application services: Auth, email, etc
What is a DDD Aggregate
Source: https://www.youtube.com/watch?v=zlFqjD2LKlE
Aggreate is an imaginary boundary for holding data consistency for a bunch of entities, driven through the Root Entity.
Example: If I have an user entity, and session entity, and if I want to invalidate the session, the wrong way to do this is to get the user.current_session() and then do session.invalidate(). This is basically exposing session to the outer world.
The right way is to do user.invalidate_session(), where the user is the root entity here, for accessing session and maintaining data consistency.
Aggregate is a unit of consistency and concurrency. Aggregates are distinct, so they need to carry some kind of identity.
2 Users are different, having different User IDs.
Context mapping
Surprising truth about what motivates us - Autonomy, mastery and purpose This also applied to teams and bounded contexts in software
Bounded Context
Is a boundary for a model expressed in a consistent (ubiquitous) language tailored around a specific purpose
- Propagation of models ? Why bad ?
- Dependency between teams
- Mutually dependent
- Free
- Changes in one bounded context do not influence success or failure in other bounded contexts.
- Upstream/Downstream
- An upstream context will influence the downstream counterpart while the opposite might not be true
9 Patterns
- Partnership
- Shared kernel
- Physically shared artifact between two teams
- Examples: Shared JARs or database
- Customer / supplier
- Conformist
- Take the model with upstream and just use it. Represented as CF
- Anticorruption layer
- separate ways
- Open / Host service
- one API for several consumers
- Common, general purpose model and functionality
- Upstream service
- Published language
- Big Ball of Mud