ERIC EVANS SPEAKS
Eric Evans, the author of Domain-Driven Design, has
been programming and designing systems for 25
He asserts that for most software projects, the
primary focus should be on the domain and domain
“Domain-driven design flows from the premise that the heart of
software development is knowledge of the subject matter and
finding useful ways of understanding that subject matter. The
complexity that we should be tackling is the complexity of the
domain itself -- not the technical architecture, not the user
interface, not even specific features. This means designing
everything around our understanding and conception of the most
essential concepts of the business and justifying any other
development by how it supports that core.”
“The goal of domain-driven design is to create
better software by focusing on a model of the
domain rather than the technology.”
DDD LEADS TO MODEL-DRIVEN DESIGN
Domain-Driven Design leads to Model-Driven
Design since developers capture their knowledge
of a domain in models
A model-driven design is software structured around
a set o domain concepts
E.g.: A model-driven design for a UI framework is
one in which UI concepts, such as windows and
Teams who embrace model-driven design are aware
that a change to the code IS a change to the model
(and vice versa)
MODEL-DRIVEN DESIGN BENEFITS DDD
The model and its implementation shape each other
The link between model and code makes the model
relevant and ensures that the work spent on analysis is not
The model creates a language used by all team
The language spreads domain knowledge throughout a
It allows developers to speak to domain experts (e.g. users)
The model is distilled knowledge
Analysis is hard; we need to capture the information we get
The model is the team’s agreed-upon way of structuring
domain knowledge and distinguishing the elements of most
The heart of software is its ability to solve domain-related
for its users
Software functionality either solves a domain-related problem
or performs a domain-related task
All other features support these two goals
When a domain is complex, it becomes difficult to
To be successful, developers must steep themselves in the
Problem: Most developers are not interested in this!
Domain work is messy and demands a lot of knowledge not
necessarily related to computer science
Developers enjoy quantifiable problems that exercise their
But, domain complexity has to be tackled head-on by
developers or they risk irrelevance!
Domain modeling requires processing (crunching)
In the same way that financial analysts crunch numbers
While speaking with domain experts, a domain
try one organizing idea (set of concepts) after another
create models, try them out, reject some, transform others
Success is achieved when the modeler has created a
set of abstract concepts that makes sense of all the
details provided by the domain experts
Domain experts are a critical part of the process
Without them, developers tend to create models with
concepts that seem naive and shallow to domain experts
INGREDIENTS OF EFFECTIVE MODELING
Bind the model and the implementation
As a model is developed, create rapid prototypes that
test the domain
These prototypes contain primarily domain concepts
no UI, no persistence, no infrastructure
Develop a knowledge-rich model
The objects of your model should have behavior and
may follow rules
The model should not be just a data schema (think
class diagram) but should express behavior,
constraints, etc. that help solve domain related
Models capture more information than just the
“classes” of a domain
it goes beyond the “find the nouns and verbs”
heuristic of some object-oriented models
In particular, models capture behavior, business
activities, and business rules (policies,
EXAMPLE: MODELING BUSINESS RULES
The association might look like this:
EXAMPLE: OVER BOOKING CARGO?
A standard practice in the shipping industry is to
accept more cargo than a particular ship can
carry on voyage
This is know as “overbooking” and is used because
there are typically always last-minute cancellations
One way of specifying the overbooking policy is via a
percentage of the ship’s total capacity ~ 10%
EXAMPLE: HIDDEN KNOWLEDGE PROBLEM
Overbooking policy is not reflected in our model
The policy has been recorded in a requirements
document and hidden away inside one method in our
Domain-Driven Design recommends making that
knowledge a part of the model: change the model,
change the code (and vice versa)
Our code would now look like this:
and the OverBookingPolicy class would have a method:
It is not practical for software developers to
become domain experts, or for domain experts to
become software developers.
Both parties can easily become confused by the
plethora of undefined terminology and acronyms.
Solution: Ubiquitous Language.
Domain-Driven Design is overkill.
Very little domain logic.
Mostly data entry / retrieval.
Prototype or a “one off.”
Low-level of modeling skill.
Solution: Smart UI
Put the business logic in the user interface.
Create a separate user interface for every
Store all data in a shared relational database.
Program in 4GL languages and use rapid
prototyping tools; Java/C# is overkill.
Lots and lots of complicated domain logic.
Long-lived project lifetime.
High-level of modeling skill.
Solution: (Domain) Model-Driven Design.
Uses a single model for both analysis (to understand
the domain) and design (to implement the software).
Requires an iterative development process and
Developers are also modelers.
This is hard.
ASIDE: THE MODEL DEBATE
What is the relationship between the
domain model and the source code?
“Tightly relating the code to an underlying model
gives the code meaning and
makes the model relevant.”
There is too much crap in my domain logic.
I wish I could pull all of this crap out so that the
model is easier to see and change.
Solution: Layered Architecture
Crap is a scientific term.
USER INTERFACE LAYER
Presents information to the user and interprets
the user's commands.
Defines the application services: what the
software actually does for the user.
Orchestrates the domain objects to implement
these application services.
Has state reflecting the progress of a service call
This layer is kept thin.
Represents concepts of the business, information
about the business situation, and business rules.
Maintains state reflecting the business situation.
This layer is the heart of business software.
Provides generic technical capabilities that
support the higher layers.
Rendering UI widgets
This layer could be a library or a framework.
The object graph is biconnected.
Every object has at least two references to other
Hard to enforce invariants.
Hard to implement database transactions
without touching every object in the system.
“A cluster of associated objects that are treated as a
unit with regard to data changes.”
All external access to the cluster
is through a single root Entity.
The root Entity enforces invariants
among the other objects.
Is the root Entity responsible for creating the
Observation: Creation code is different than run-
time behavior code.
“Encapsulates the knowledge necessary
for complex object creation.”
How do you find an Aggregate?
Navigate a network of object references.
Pollutes the domain objects with extra references.
Pull data from the database.
Should SQL go inside the domain objects?
May violate data hiding principles.
“Encapsulates database storage,
retrieval, and search behavior which
emulates a collection of objects.”
Looks like java.util.Collection.
Acts like a relational database.