Taming Complex Domains with Domain Driven Design

Taming complex
domains with
Domain Driven
Design

Copyright Alberto Brandolini 2008

About me
10 years experience in IT, mainly as a consultant
Took part in many large scale projects
Government(s)
Banking
Insurances
A foot in the process, the other in the architecture.
Seasoned trainer
My blog: http://ziobrando.blogspot.com
My e-mail:
alberto.brandolini@gmail.com


What are we
talking about?

The DDD book, by Eric
Evans has been published in
2004, gaining increasing
momentum since then.


...from the source

Domain-driven design is not a
technology or a methodology.
It is a way of thinking and a set of
priorities, aimed at accelerating
software projects that have to deal
with complicated domains.

DDD - what it is and
why it matters W
i

This is an approach that goes from small to large scale.

why it matters W

It’s a set of proven modeling techniques i

especially targeted to complex applications.


why it matters W


It’s a set of principles and practices
supporting the development process.


why it matters W


It’s a set of patterns that support a clean and
coherent view of the domain model.


why it matters W


It’s a set of patterns that support a clean and
coherent view of the domain model.
It’s a set of pragmatic strategies allowing
applications to scale in size and complexity
maintaining their integrity. Copyright Alberto Brandolini 2008

Design pattern book?

Wasn’t OOP enough?
OOP original value proposition has been
enhanced in many directions primarily addressing
architecture and design issues.

Still, OOP falls short and lacks well established
disciplines to model complex domains.

In the past, tools and frameworks have twisted
the original OO paradigm silently constraining
domain modeling techniques Copyright Alberto Brandolini 2008
The original OOP hype was centered on the myth of reuse. Really reusable solutions appeared
in the form of patterns (Design patterns, GRASP patterns, Architectural patterns and so on).
They primarily focused on design and architecture, also because they were domain-neutral
and allowed for potentially higher reusability.

The only notable effort to ﬁll this gap is Martin Fowler’s book Analysis Patterns.

The premise

The primary focus should be
on domain and domain logic

Complex domain design should
be based on a model

Technology, per se, does not provide a key competitive advantage in building a competitive
software.

The ecosystem

Agile Software
Development practices
should be in place, allowing
short iterations to gather
users’ feedback from users
and domain experts.

Why do we need a
model?
A model is a representation of the
domain serving a speciﬁc purpose.
There is no “perfect” model for a
given domain.
A good model is tailored on the
given purpose.

Expressing the model
Model and the underlying design
must evolve in sync.
Model
Code is the ultimate way to
express the model.
Design
Intermediate artifacts, diagrams
and docs serve a temporary goal.


Lo-ﬁ UML
Many tools twisted the purpose of UML, focusing
on code generation capabilities, reverse
engineering, color gradients and so on.
but
Modeling activity is too crucial to be performed
in isolation.
Heavyweight UML might prevent domain experts
from contributing to the model.
Use a valuable subset of UML to communicate
effectively with the team and domain experts.
One notable exception is the old TogetherJ, whose roundtrip features might help to keep
diagrams and code in-sync. But problems related to isolation and shutting down the
communication channel with the domain expert were still open.

The Mindset


Continuous Learning
Learning about the underlying domain is often
considered a byproduct or a side-effect.

Many projects sponsor learning new
technologies or architectures, but rarely
consider the domain among the valuable topics.

Continuous learning, instead, is a key
activity for a successful project, and is the only
way to deliver a useful model

Working with domain
experts
Team and domain experts
continuously reﬁne their
model and their
understanding of the
domain.
Communication channel
between the domain
expert and the team must
be kept open.

Knowledge
crunching
Our job is to be able to translate
any domain into the most useful
model.
To achieve this goal we must crunch
the amount of knowledge available
from domain experts, users, books...

Ubiquitous
language
Knowledge about the domain is expressed
in a ubiquitous language, allowing
domain experts, designers, testers, and
developers to share and maintain the
same vision.
Terms of the ubiquitous language must be
unambiguous and agreed by all parties.

The Breakthrough

• Learning does not happen brick by
brick
• Learning is not a linear process
• A deeper level of knowledge implies
refactoring of the existing solution

This is a key moment in DDD. When we recognize that our understanding of the domain has
improved also the code must follow. This is tricky and hard to achieve. An exploratory
session backed up by tests is often the best solution.

Refactoring the
Domain
Our knowledge of the Domain is challenged by
Continuous Learning.
The more we learn, the more the existing model
must be evolved accordingly.
Brainstorming and Refactoring help
experimenting new versions of the domain
model.
Availability of an automated test suite greatly
enhances our domain refactoring capabilities.
Our vision of the domain and our implementation must be strictly tied.
Consciously leaving a gap between the ideal implementation and the real one complicates
domain management providing little value.

This is an argument that an be vigorously opposed by project managers, if they’re thinking
short-term. The main weapons to make this option viable are:
• having the implementation as close as possible to our understanding of the model (gaps
build on gaps)
• having a test suite in place, targeted against our domain objects.
• Experiment. Assumptions are generally negative: estimations of refactoring tasks are often
larger than necessary. Ripple effects are valuable knowledge

Implementing a model:

DDD Building
Blocks

Building our model
Regardless of the domain
complexity, an application
domain might be represented
with speciﬁc classes, assuming
speciﬁc roles and partitioning
the domain model in well
structured regions

Building blocks
On a small scale, every domain exposes a peculiar but
repeatable structure, organized in families of classes
with speciﬁc purposes.
Entities
Value Objects
Services
Modules
Aggregates
Factories
Repositories
Aggregate Objects
Domain Events Copyright Alberto Brandolini 2008

Entities

• Objects with an identity and a state.
• Generally with a counterpart on persistent
storage support.
• Their state evolves as long as the
application lives


Value Objects

Have no conceptual identity.
Can be designed as immutable
Can be shared between different
entities


Services

A service represent an operation which is
peculiar to the domain model
The interface is deﬁned in term of other
elements of the domain model
The operation is stateless

Domain speciﬁc services belongs to the
Domain layer

Modules
Modules are a way to partition the system
to make it more manageable
Many languages implement them as
packages
In DDD, packages should be divided
according to the purpose instead of the
object type.
Object type should result evident by the
Naming Convention

Aggregates
A cluster of associated objects that we
treat as a unit for he purpose of data
changes.
Guarantees integrity of the enclosed
Entities and Value Object
A speciﬁc entity is selected as a root of
the aggregate


Aggregate Root
contours
Aggregate roots and
entities partition the
domain into non
overlapping <<Aggregate Root>> <<Entity>>

regions.
A B

Access to entities
<<Entity>>
C

<<Aggregate Root>> <<Entity>>

might only be D F

performed through
the corresponding <<Entity>>
E
<<Entity>>
G

root.
Interestingly, this works pretty well to solve intricated double update problems or to deﬁne
lazy loading strategies, and so on.

Factories
Correct creation of an instance of a
complex object does not belong to the
object itself.
Speciﬁc objects have the responsibility of
creating the requested object instances


Repositories
Repositories provide data retrieval
capabilities to the domain model
providing the illusion of an in-memory
collection.
They abstract interaction with the
underlying persistence layer offering
services in terms of domain model
elements

Aggregate Object
Sometimes the responsibilty of the whole aggregate
doesn’t really belong to the Aggregate Root entity.

Sometimes preserving integrity of the aggregate as a
whole is a responsibility that deserves a role of its own

An Aggregate Object might coordinate invariants
checking and state management between the different
entities of the aggregate


Domain Event
Sometimes our application is just tracking things that
happen.

Those are normally modeled as Value Objects, but
there’s no point in sharing, cause those events are
intrinsically unique.

a Domain Event represents an event which is
meaningful in the domain.

There’s a similar concept in UML in Colour, which is called Moment-interval.

Putting it all together...
Taken one by one, the patterns are not a
revolution.
These patterns have been collected from
successful project, not invented.

Yet, taken together, they provide a
scalable approach to manage complicated
domains.


Renewing building
blocks
DDD is a technology-neutral
paradigm, but since the original
enunciation the technical
landscape evolved.

Some problems are no longer open, or the DDD solution suggested in the book

The good news
Many of the original shortcomings of
mainstream architecture blueprints
have recently downsized.
POJO based frameworks, ORM
frameworks might offer a
mainstream solution to some of the
most common issues.
Some problems are no longer open, or the DDD solution suggested in the book

Don’t ﬁght your
frameworks
DDD is a set of principles, rather than
a reference implementation.

Choose the solution that ﬁts best your
development scenario, but keep track of
the trade-off cost

Some problems are no longer open, or the DDD solution suggested in the book might look
obsolete nowadays. Factories are often managed by Spring or Hibernate

Strategic Domain
Driven Design

Increased project size
introduces new challenges
to project management,
architecture and domain
modeling as well

In a software development
project, different ﬁnite
resources have to be
managed and wisely allocated,
to deliver the highest possible
value.
This applies to time and budget,
but also to skills, talent,
knowledge and expertise

Different domains are
subjected to different
forces resulting in
different speeds
and directions of the
evolutions

Interlude: Biased history
of a language

Many sources inﬂuenced
the original model
... and the Romans were amongst then

reference implementations
helped to establish a
standard Copyright Alberto Brandolini 2008

Large scale adoption of
a standard bred
variations

A subset of the
domain
became a
lingua franca
allowing
interoperability
between
different
systems Copyright Alberto Brandolini 2008
They were not originally meant to be part of the system

Despite all the efforts to
produce extensive
documentation, single
domains still evolve

Some
domains
do not
adhere
to
standards


Some ... and
domains probably
do not never
adhere will
to
standards


Still, new requirements and
media might introduce changes
also in consolidated domains


Large-scale DDD


Size matters
larger or more complicated domains cannot be
managed in the same way:
- purposes start to diverge
- communication is less effective as team size
increases
- efforts to maintain a coherent view might
outweigh its beneﬁts


Partitioning
- Larger domains can be partitioned in order
to maintain a coherent view, in a bounded
context.
- The overall view must still be shared, as well
as some key artifacts
- Splitting areas provides a more efﬁcient way
to evolve in a coherent context.
- Partitioning isn’t meant to be necessarily a
phisical action. Sometimes it’s just accepting
reality.

Context map
Model in
context

Translation Map

Model in
context

A model is valid in a specific context. Different
context might need different version of the model, due
to specific purposes
So, we need a way to define contours and boundaries at a conceptual level.
This will help us to have a snapshot of the exact shape of the system.

Shaping
subdomains
Models must preserve their
integrity.
A well defined domain can be
defined by a well defined team
serving a specific goal.

A context is an environment (team, project, subproject) where a model can have its own
integrity.

Prioritizing
subdomains
Areas that provide the most
significant value to the
application must be highlighted
and isolated from the
surroundings

It takes significant skills and energy to build a good model. We can’t apply them equally in
the large. We must find the sweet spot and focus where it matters more.

Core Domain

The portion of the application that provides
the most value to the enterprise.
Focus on this portion of the system to provide
the most signiﬁcant value.
Preserve the domain from external inﬂuences


Generic
Subdomain
A portion of the system which
is not delivering speciﬁc value.
Sub optimal or tactical
solutions are viable
opportunities:
build, outsource, buy, reuse.
This portion of the application is needed, but making it perfect would not provide an
signigicant increase in the value.
The driver to determine value is always the business, so keep aligne with the business drivers
for your domain.

Shared Kernel Shared Kernel
Model in
context
Model in
context

Translation Map

An agreed subset of the system might be shared
between different teams.
Strict coordination rules apply
Some portions of your application might be shared. Different teams might need to coordinate
evolution of a shared portion of the system. However, coordination is expensive and it’s not
always applicable.

Customer Supplier
Establish a customer-supplier relationship
between the teams.
Development processes and planning will
be correlated.
Share a translation map between the
teams

There’s a formal agreement in place, meaning that both team have to agree on some
practices and relationship between the two.
This clearly has a cost, which has to be evaluated, within the organization.

Conformist

Passively adapt to another
team’s model.
Implement a non-optimal
solution in a subdomain, to
decrease communication costs
between the team
If the Customer Supplier does not work... the battle could just be not worth the ﬁght. This is
a cheaper option from the organization’s point of view, but will also provide less value to the
application.

Anticorruption
Layer
A defense mechanism might be necessary to
prevent leaking from one domain to another
one.
Integrating different domains does not mean that
they serve the same purpose.

An anti-corruption layer isolates the
translation and adaptation role in a speciﬁc layer
In some cases the borderline between two contexts needs to be guarded, to prevent concepts
to leak in outside their boundaries.

The same concepts might have different representations in the two contexts. The ACL is
where the translation happens, even in a “dirty way”.

Open Host

Sometimes, we know only one side of the
boundary.
Integration might happen with an undefined
number of external context.
We are not free anymore to define ad-hoc
policies: an Open Host defines this type of
relationship
This is a fairly common situation in a SOA context.
It can easily be tracked down to the English language example, meaning that once shared (as
it is in Europe) a model isn’t free to evolve, because it turns into an integration level artifact.

Published
Language
Opening a door to multiple context means giving
up the freedom to evolve the underlying model.
Sometimes, the language spoken at the border
becomes a model on its own.
Sometimes, a standard language already exists on
a given domain, increasing integration
possibilities.
SOA again gives us some examples: you can create a web service in seconds, exposing your
domain objects. But once published you’re sometimes givin’up the possibility to evolve. A
service exposed to an open channel/bus means that there is anothe model, living on the
channel.

Separate ways

Sometimes, the cost of integration is higher than
the integration beneﬁts.
Short term, quick or simply unrelated solution
does not necessarily belong to the big plan
Do we really need to integrate them anyway?


References
Domain Driven Design
Eric Evans
Addison Wesley


References
Apply Domain Driven
Design and Patterns
Jimmy Nilsson
Addison Wesley


Domain Driven Design
discussion groups

• http://tech.groups.yahoo.com/group/
domaindrivendesign/
• http://it.groups.yahoo.com/group/DDD-IT/


Questions?


Taming Complex Domains with Domain Driven Design

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Taming Complex Domains with Domain Driven Design

Similar a Taming Complex Domains with Domain Driven Design (20)

Más de Alberto Brandolini

Más de Alberto Brandolini (20)

Último

Último (20)

Taming Complex Domains with Domain Driven Design