4. ERIC EVANS SPEAKS
Eric Evans, the author of Domain-Driven Design, has
been programming and designing systems for 25
years
He asserts that for most software projects, the
primary focus should be on the domain and domain
logic
“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.”
From http://domaindrivendesign.org/articles/blog/evans_eric_ddd_and_mdd.html
5. “The goal of domain-driven design is to create
better software by focusing on a model of the
domain rather than the technology.”
6. DDD LEADS TO MODEL-DRIVEN DESIGN
Domain-Driven Design leads to Model-Driven
Design since developers capture their knowledge
of a domain in models
In particular
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
menus
Teams who embrace model-driven design are aware
that a change to the code IS a change to the model
(and vice versa)
7. 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
wasted
The model creates a language used by all team
members
The language spreads domain knowledge throughout a
team
It allows developers to speak to domain experts (e.g. users)
without translation
The model is distilled knowledge
Analysis is hard; we need to capture the information we get
from it
The model is the team’s agreed-upon way of structuring
domain knowledge and distinguishing the elements of most
interest
8. TACKLING COMPLEXITY
The heart of software is its ability to solve domain-related
problems
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
accomplish this
To be successful, developers must steep themselves in the
domain
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
technical skills!
But, domain complexity has to be tackled head-on by
developers or they risk irrelevance!
9. CRUNCHING KNOWLEDGE
Domain modeling requires processing (crunching)
knowledge
In the same way that financial analysts crunch numbers
While speaking with domain experts, a domain
modeler will
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
10. 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
problems
11. KNOWLEDGE-RICH DESIGN
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,
constraints, etc.)
13. 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%
14. 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
application
Domain-Driven Design recommends making that
knowledge a part of the model: change the model,
change the code (and vice versa)
15. EXAMPLE: CONTINUED,
Our code would now look like this:
and the OverBookingPolicy class would have a method:
16. PROBLEM
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.
18. UBIQUITOUS LANGUAGE
“A language structured around the
domain model and used by all team
members to connect all the activities
of the team with the software.”
21. PROBLEM
Domain-Driven Design is overkill.
Very little domain logic.
Mostly data entry / retrieval.
Short deadline.
Prototype or a “one off.”
Low-level of modeling skill.
Solution: Smart UI
22. SMART UI
Put the business logic in the user interface.
Create a separate user interface for every
application function.
Store all data in a shared relational database.
Program in 4GL languages and use rapid
prototyping tools; Java/C# is overkill.
23. PROBLEM
Lots and lots of complicated domain logic.
Long-lived project lifetime.
Ambitious goals.
High-level of modeling skill.
Solution: (Domain) Model-Driven Design.
24. 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
continuous refactoring.
Developers are also modelers.
This is hard.
25. 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.”
26. PROBLEM
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.
28. USER INTERFACE LAYER
Presents information to the user and interprets
the user's commands.
29. APPLICATION LAYER
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
in execution.
This layer is kept thin.
30. DOMAIN LAYER
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.
31. INFRASTRUCTURE LAYER
Provides generic technical capabilities that
support the higher layers.
Message sending
Persistence
Rendering UI widgets
Etc.
This layer could be a library or a framework.
33. ENTITIES
“Objects which are not defined by their attributes,
but rather by a thread of
continuity and identity, which remains
the same throughout the life of the
software and even beyond.”
34. VALUE OBJECTS
“Immutable objects that have no
conceptual identity and whose only
purpose is to describe some attribute
of another object.”
35. SERVICES
“Objects that have no state and whose
only purpose is to represent an operation
on the domain itself.”
39. PROBLEM
The object graph is biconnected.
Every object has at least two references to other
objects.
Hard to enforce invariants.
Hard to implement database transactions
without touching every object in the system.
Solution: Aggregate.
40. AGGREGATE
“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.
41. PROBLEM
Is the root Entity responsible for creating the
Aggregate?
Observation: Creation code is different than run-
time behavior code.
Solution: Factory.
42. FACTORY
“Encapsulates the knowledge necessary
for complex object creation.”
Relevant patterns:
Factory Method
Abstract Factory
Builder
43. PROBLEM
How do you find an Aggregate?
Navigate a network of object references.
Increases coupling.
Pollutes the domain objects with extra references.
Pull data from the database.
Should SQL go inside the domain objects?
May violate data hiding principles.
Solution: Repository.
44. REPOSITORY
“Encapsulates database storage,
retrieval, and search behavior which
emulates a collection of objects.”
Looks like java.util.Collection.
Acts like a relational database.
