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

User Interface

Shows information to the user

Interprets user commands

Application Layer

Provides functionalities via domain objects

Thin, coordinates

This is what “User Stories” are all about

Domain Layer

It’s the place for the business concepts, information, rules, etc.

Infrastructure Layer

Provides generic technical capabilities that support the higher layers.

Modeling Materials

Base Elements

Entities

Value Objects

Associations

Life Cycle

Aggregates

Factories

Repositories

Complexity Handling

Services

Modules

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

Life Cycle

Aggregates

Boundaries between groups of one or more Entities/Value Objects

Aggregates

They have a root Entity/Value Object, and specify global/local scope for identities

Aggregates

Define scope of invariants/constraints, and transactionality (atomic/eventual consistency)

Factories

Complex object creation belongs to the Domain layer

But usually doesn’t belong into any specific Entity/Value Object/ Aggregate

Enter Factories

Repositories

They provide the “illusion of an in-memory collection of all objects”

Provide access to root objects not easily reachable via Associations

Abstract the specific storage technology used

Complexity Handling

Services

Execution in the Kingdom of Nouns

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 and high cohesion between them.

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, but concepts

An Extended Example