Introduction to Domain driven design

Software Architecture Meetup
November 2018

Domain Driven Design (DDD)
Muhammad Ali
Software Architect VentureDive

Conway's law
“Any organization that designs a system (defined more broadly here than just
information systems) will inevitably produce a design whose structure is a copy of the
organization's communication structure.”

What is domain-driven design
● Domain-Driven Design is an approach to the development of complex software in
which we:
○ Focus on core domain
○ Explore models in a creative collaboration of domain practitioners and software practitioners
○ Speak a ubiquitous language with in an explicitly bounded context

Goal
● A domain specific project that needs to leverage multiple realms of expertise
specifically
○ Design and Developer expertise
○ Domain specific expertise

Complication
● Most of the times developers speak in terms of Objects, composition, aggregation,
inheritance, polymorphism, pure functions etc.
● They talk more about technical solution rather than the problem itself.
● At times they don’t understand the underlying complexity and overcommit.
● Domain expert don’t know any of these, he has his own jargons regarding the
domain.
● For example marketing people talking about leads, ads, campaigns, budgeting
units etc.
● Similarly domain expert in airline talking about crew planning, SAFE, roster
planning, FBO, PFA etc.

Solution
● Strengthen the communication process and establish a methodology for making
those communication more robust
● This is primarily accomplished by developing a UBIQUITOUS LANGUAGE and
single model
● Make sure your developers speak this ubiquitous language.
● Persistent use of the UBIQUITOUS LANGUAGE will force the model's
weaknesses into the open
● Building a language like this has a clear outcome:
○ Language and model are strongly interconnected with each other
○ Any changes to the language will be recognized as changes in the domain model

Domain Model
● A system of abstraction that describes selected aspects of a domain and can be
used to solve problems related to that domain.
● A domain model in not a particular(UML) diagram(unlike Model-Driven
Design), it is the idea that diagram is intended to convey.
● Model can be an expression in natural language, code or a diagram.
● Model is not a design artifact
● Model are the backbone of domain-driven design
● The model is distilled knowledge
● It is not just the knowledge in a domain expert's head; it is a rigorously organized
and selective abstraction of that knowledge

Implementation
● Once Domain Model is defined, you can identify different components based on
their properties
● You can divide your solution into different layers(so called layered architecture,
MVP, MVC etc)
● For example following we can break down our solution into following layers
○ Presentation Layer (UI or Rest/SOAP)
○ Application Layer (Define the jobs that software is supposed to do and direct the expressive
domain objects to work out problems.)
○ Domain Layer(Contains Business Logic)
○ Infrastructure Layer(Provides generic technical capabilities, like message sending, persistence etc.)
● There can be multiple layers with different names however Domain-Driven
design only requires domain layer.

Entities
● An object defined primarily by its identity is called an Entity.
● Each entity must have an operational way of establishing its identity with another
object
● An identifying attribute must be guaranteed to be unique within the system
however that system is defined, even if distributed, even when objects are
archived

Value Objects
● An object that represents a descriptive aspect of the domain with no conceptual
identity is called a Value Object.
● The attributes that make up a Value Object should form a conceptual whole
● Immutability should also be considered when designing Value Objects
● As long as a Value Object is immutable, change management is simple

Services
● There are important domain operations that can't find a natural home in an Entity
or Value Object
● A Service is an operation offered as an interface that stands alone in the model,
without encapsulating state, as Entities and Value Objects do.
● Services are a common pattern in technical frameworks, but they can also apply in
the domain layer.
● A good service has following characteristics
○ The interface is defined in terms of other elements of the domain model
○ The operation relates to a domain concept that is not a natural part of an Entity or Value Object.

Aggregates
● An aggregate is a cluster of domain objects that can be treated as a single unit
● Aggregates are the basic element of transfer of data storage - you request to load
or save whole aggregates. Transactions should not cross aggregate boundaries.
● An aggregate will have one of its component objects be the aggregate root.
● Any references from outside the aggregate should only go to the aggregate root.
● The root can thus ensure the integrity of the aggregate as a whole.
● 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 to any object
within the aggregate boundary is committed, all invariants of the whole aggregate
must be satisfied.

Bounded Context
● Bounded Context is a central pattern in Domain-Driven Design
● DDD deals with large models by dividing them into different Bounded Contexts
and being explicit about their interrelationships
● Total unification of the domain model for a large system will not be feasible or
cost-effective
● So instead DDD divides up a large system into Bounded Contexts, each of which
can have a unified model

Context Map
● An individual Bounded Context still does not provide a global view. The context
of other models may still be vague and in flux
● Code reuse between Bounded Context is a hazard to be avoided.
● A Context Map is the overlap between project management and software design.
● A Context Map is a document which outlines the different Bounded Contexts and
the relationships between them.
● The level of detail may vary. What it is important is that everyone working on the
project shares and understands it.

Introduction to Domain driven design

Recommended

More Related Content

Similar to Introduction to Domain driven design (20)

More from Muhammad Ali (8)

Recently uploaded (20)

Introduction to Domain driven design