In recent conversations with coworkers, the topic of Domain-Driven Design has
arisen on more than a few occasions in design and architecture meetings.
“Have you read it?” a coworker asked, “I think it’d help us a lot.”
My desire is to share my outlines of the book chapter-by-chapter,
hopefully once a week.
Chapter 1: Getting Started with DDD
Can I DDD?
- DDD helps us design software models where “our design is exactly how
the software works” (1).
- DDD isn’t a technology, it’s a set of principles that involve
discussion, listening, and business value so you can centralize
- The main principle here is that we must “understand the business in
which our software works” (3). This means we learn from domain experts
in our field.
- What is a domain model? an object model where objects have
data/persistence concerns with an accurate business meaning.
Why You Should Do DDD
- Domain experts and devs on same playing field, cooperation required as
one team. (Agile teams, anyone?)
- The business can learn more about itself through the questions asked
- Knowledge is centralized.
- Zero translations between domain experts and software devs and
- “The design is the code, and code is the design.” (7)
- It is not without up-front cost
- The schism between business domain experts and software developers
puts your project (and your business) at a risk.
- The more time passes, the greater the divide grows.
- DDD brings domain experts and software developers together to develop
software that reflects the business domain mental model.
- Oftentimes this requires that they jointly develop a “Ubiquitous
Language” - a shared vocabulary and set of concepts that are jointly
spoken by everybody.
- DDD produces software that is better designed & architected -> better testable ->
- Take heed: DDD should only be used to simplify your domain. If the net
cost of implementing DDD is only going to add complexity, then you
should stay away.
Domain model health
- As time passes, our domain models can become
and lose their expressive capabilities and clean boundaries. This can
lead to spaghetti code and a violation of object responsibilities.
- Why do anemic domain models hurt us? They claim to be well-formed
models but they hide a badly designed system that is still unfocused
in what it does. (Andrew: I’ve seen a lot of Service objects that
claim to be services but really are long scripts to get things done.
There might be a cost of designing the Service interface, but inside
things are just as messy as before we got there.)
- Seems like Vernon is blaming the influence of IDEs for Visual Basic as
they influenced Java libraries – too many explicit getters and
- Vernon throws up some code samples comparing two different code
samples – one with an anemic model that looks like a long string of
commands and another with descriptive method names. He makes the case
that simply reading the code is documentation of the domain itself.
How to do DDD
- Have a Ubiquitous Language
where the team of domain experts share the language together, from
domain experts to programmers.
Steps to coming up with a language:
- Draw out the domain and label it.
- Make a glossary of terms and definitions.
- Have the team review the language document.
- Note that a Ubiquitous Language is specific to the context it is
implemented in. In other words, there is one Ubiquitous Language per
Business value of DDD
- The organization gains a useful model of its domain
- The precise definition of the business is developed
- Domain experts contribute to software design.
- A better user experience is gained.
- Clean boundaries for models keep them pure.
- Enterprise architecture is better designed.
- Continuous modeling is used – the working software we produce is the
model we worked so hard to create.
- New tools and patterns are used.
- The time and effort required to think about the busines domain,
research concepts, and converse with domain experts.
- It may be hard to get a domain expert involved due to their
- There is a lot of thought required to clarify pure models and do
- The Core Domain is the part of your application that has key and
important business value – and may require high thought and attention
- Sometimes DDD may not be the right fit for you – if you have a lot of
experienced developers who are very comfortable with domain modeling,
you may be better off trusting their opinion.
DDD is not heavy.
- It fits into any Agile or XP framework. It leans into TDD, eg: you use
TDD to develop a new domain model that describes how it interacts with
other existing models. You go through the red-green-refactor cycle.
- DDD promotes lightweight development. As domain experts read the code, they
are able to provide in-flight feedback to the development of the