Architect Software with Domain Driven Design

What is Domain Driven Design ?

Domain-Driven Design(DDD) is an approach to software development for complex businesses by focusing the team’s attention on deeper knowledge of the Domain(Business). This is achieved by implementing domain models based on business processes and rules.

The domain represents a real-world industry: e-commerce, insurance, banking, hr, etc, and the Domain Expert represents the specialist in that field.

The key concepts (patterns) of DDD were defined in 2004 by Eric Evans in his book “Domain-Driven Design: Tackling Complexity in the Heart of Software“.

Why DDD ?

• To architect better software that solve business needs.
• To create long-lasting software implementations of complex domains.

DDD is splitted in 2 main areas, the business techniques: Strategic Design Tools and the technical approach: Tactical Design Tools.

What is a Service ?

It is the project/application structured like:

1. Packed up/deployed app (exe, jar, etc)
2. Objects, Classes, Methods
3. OOP & Design Patterns (reusable solutions)
4. Modules
5. Layered architecture
6. Service

A domain can have more sub-domains which can have more services which forms the infrastructure.

Strategic Design

Often the software engineers tend to think at the software in terms of objects and methods (Object Oriented Design), but… is that enough ?

• Is a good software built only with Java, IDE and JUnit ?
• Can you build a great house only from bricks and wood ?
• Can a car be done only from engine, steel and oil ?
• Is a book only a collection of a language words ?

Strategic Design is meant to see the big picture of the project and to think in terms of Contexts (a setting which determines the meaning of a word/statement).

When modeling a domain, developers and business should share a common language (Ubiquitous Language) that both understand and mean the same thing.

Every term in the ubiquitous language has a well defined, unique meaning within the boundaries of the (sub)-system under design. This boundary is called Bounded Context.

Layers like API, Persistence/Infrastructure, UI, Domain, are simply implementations of separation of concerns principle so basically a bounded context.

Context Map represents the relationships between the bounded contexts.

Case scenario: build a residential house complex

The main steps before implementation would be to:

• Define the type of houses
• Talk with a domain expert
• Find out the core values
• Check what others have done

Domain = residential house building

Model = abstract solution of domain

Sub-Domains = gardens, parking, shop, gym, pool, etc

Bounded Context = house building, shop, gym (an object or person may have different meaning/role in each of this context)

Ubiquitous Language = living-room, master-bedroom, garage (terms describing the parts of the building)

Implementing DDD

Vaughn Vernon presented same practical DDD implementations in his books Implementing Domain-Driven Design (2013) and Domain-Driven Design Distilled (2016).

How to discuss with domain experts

In the past this was done using UML Diagrams (Use Case, Sequence, Activity, Entity Relationship) but DDD comes with a more efficient approach called Event Storming.

Event Storming is a brain storming workshop among domain and technology experts in order to achieve a common understanding of the domain and identify it’s right constraints.

There’s also a facilitator participant whose role is to keep engaged and focused the other ones.

Event Storming Steps

1. Write on colored sticky notes the ubiquitous terms like: events, commands, aggregates, policies, errors, processes and roles
2. Write the events in sequence on a white board (see Miro online whiteboard)
3. Add the sticky notes on board
4. Identify the bounded context
5. Reiterate the process

Tactical Design

Entity – business object with identity, continuity and lifecycle through the business process (Customer, Employee)

Value Object – an object without identity, an entity attribute/metadata (Address)

Service – actions/operations that don’t belong to an Entity or VO (Email Notification)

Aggregates – a cluster of associated objects treated as a unit for the purpose of data changes.

Repository– like a DAO: saves and loads objects to/from a storage (usually a database).

Each Aggregate has a root and a boundary. The boundary defines what is inside the Aggregate and the root is a single, specific Entity inside the Aggregate.

The Aggregate needs to follow these rules:

• The root is the only member of the Aggregate that outside objects are allowed to hold references to but the objects within the boundary may hold references to each other (local identity).
• Only Aggregate Roots have a Repository (obtained directly with database queries).
• Objects within the Aggregate can hold references to other Aggregate roots.
• A delete operation must remove everything within the Aggregate boundary at once.
• When a change to any object within the Aggregate boundary is committed, all invariants of the whole Aggregate must be satisfied.
• When a change spans across Aggregate boundaries, invariants spanning across boundaries might not be enforced at all times.

DDD is widely used to implement microservices applications.

A monolithicapplication puts all its functionality into a single process and scales by replicating the monolith on multiple servers.

A microservices architecture has each functional element into a separate service and scales by distributing these services across services replicating as needed.

Steps to deconstruct a Monolith with Domain Driven Design:

1. Define objectives and Key Results(OKRs)
2. Event Storm the app to identify the core domain and key constraints
3. Pick horizontal sequences of events from step 2.
4. Use C4 diagrams to identifies the components from the flow of events
5. Identify a decomposition strategy
6. Perform a SNAP (Software Non-functional Assessment Process) analysis on each component from 4.
7. Generate a backlog of user stories and link it to the OKR
8. Map the user stories to an MVP