Thinking in DDD

Improve Your Software Without Being a Guru

Domain-Driven Design is a large topic and becoming an expert
is a goal that involves years of experience. But DDD provides
so many wonderful – and powerful – ideas that you can learn
from and benefit from right away when designing or refactoring
software.
​In this half-day workshop, based on extensive real-word
experience, you will learn about some of the DDD patterns such
as bounded contexts, aggregates, anti-corruption layers as
well as the importance of thinking about your database
persistence as a cross-cutting concern. You will also gain some
insight into modeling domains and learn how to continue
questioning your processes until the "aha!" moment arrives to
you and your development team.
​With these important tools you can already begin to improve
your software design and maintainability as well as your sanity.
And with these tools in hand you can continue to explore,
practice and be guided by additional techniques that come from
Domain-Driven Design.
Agenda
• Why DDD?
• Why wait to be a DDD guru?
• Planning
• Learning about the Business Domain
• Modeling the Domain
• Understanding where the database fits in to the process
• Bounded Context: Breaking a big problem into small problems
• Implementation
• Using Rich Aggregate Roots to keep objects under control
• Considering value objects over 1:1 relationships
Solve Problems
Understand Client Needs
Build Software
Write Code
 What DDD Has to Offer

Principles History of Aligns with

Clear, testable code
& patterns to success practices from
that represents the
solve difficult with complex that come from
domain
problems projects years of experience
 It’s all about

the

Domain
Interaction
With Model a
Domain single
Experts Sub-Domain
at a time
 Purchase Materials
Engineering

Sales
Accounting

Marketing
Manage Employees
Interaction
With Model a
Domain single
Experts Sub-Domain
at a time

Implementation
of
Sub-Domains
Software implementation

Communication

Development
Process
Modeling
Drawbacks of DDD
Time and Effort
Discuss & model the problem with domain expert
Isolate domain logic from other parts of application
Learning curve (why you’re watching this course)
New principles
New patterns
New processes
Only makes sense when there is complexity in the problem
Not just CRUD or data-driven applications
Not just technical complexity without business domain complexity
Team or Company Buy-In to DDD
 Software implementation

ENTITIES

MODEL- a AGGREGATES
VALUE
DRIVEN OBJECTS
DESIGN
Communication
UBIQUITOUS
LANGUAGE

BOUNDED
CONTEXT
Modeling

ANTI-
CORRUPTION
LAYER
bit.ly/PS-DDD
 2013

2006

2003

2014
 D
is for
DOMAIN
 Domain Experts
are your

Partners
from start to finish of project
Domain Modeling
 But Where Is the Database?

But Where Is the Database?

 Data Storage
is not
the
Business Problem
Cross-Cutting Concerns
DDD Thinking: Divide and Conquer
Team Exercise
Identify Bounded Contexts for software to manage this business organization
What Behaviors are in these contexts?
Anti-Corruption Layers

Creative Commons
Insulate Bounded Contexts

Bounded
Context
Bounded
Context

Legacy
App
ACLs Between Bounded Contexts, Too
 Translate
between
foreign systems’ models & our own

using
Design patterns, e.g. : Façade, Adapter
or custom translation classes or services
Even when the other system is well
designed, it is not based on the same
model as the client.

And often the other system is not well

designed.

—Eric Evans
Domain-Driven Design
 The structure of an Anti-Corruption Layer

Source: Evans, Domain-Driven Design, p. 367

Bounded Context

public class Customer{

“Customer”
“Customer Registers” private Customer
(string Name, Date regDate){}
public static Register
(string Name, Date regDate){
return new Customer(name,regDate);
}
Ubiquitous Language
For a single Bounded Context
Used throughout that context, from
conversations to code
Recognize that a change in the ubiquitous
language is a change in the model.

—Eric Evans
Domain-Driven Design Thinking
UI Can “Link" Different Bounded Contexts
Aggregates
Product Aggregate

Product

Component
Aggregates
in the
Navigation Map

AGGREGATES

Evans,
Domain-Driven Design, p. 65
FOCUS ON
Behaviors
Schedule an appointment for a checkup
Note a pet’s weight
Request lab work
Notify pet owner of vaccinations due
Accept a new patient
Book a room

Not Attributes
Appointment.Time Pet.Name Owner.Telephone Room.Number
Team Exercise
Select some of the bounded contexts
Within that B.C. what entities belong together in an aggregate?
What is the aggregate root?
Why?
 Rich
Domain
Anemic Models
Domain Models
 Rich Domain Models over Anemic Types
Anemic for CRUD Rich for DDD

private
private
Entities
in the
Navigation Map
ENTITIES

Evans,
Domain-Driven Design, p. 65
Entities in the Appointment Scheduling Context
Relationships
A bidirectional association means that both objects can
be understood only together. When application
requirements do not call for traversal in both directions,
adding a traversal direction reduces interdependence
and simplifies the design.

—Eric Evans
Start with One-Way Relationships
Uni-Directional Associations

Doctor

Appointment Patient

Client

Client Patient
VALUE OBJECTS
Value Object
ü Measures, quantifies, or describes a thing in the
domain.
ü Identity is based on composition of values
ü Immutable
ü Compared using all values
ü No side effects
String: Our Favorite Value Object

SCAR
T
“Boots” lives with Pluralsight author, Lars Klint
 ?
Company Worth: $50,000,000
? $ 50,000,000
?Company (Entity)
ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6
Worth Unit (string): “Canadian Dollar”
Worth Amount (decimal): 50000000
Company (Entity)
ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6

{
Worth (Value Object)
Worth Monetary Unit (string) “Canadian Dollar”
Amount (decimal): 50000000
Source:http://fit.c2.com/wiki.cgi?WholeValue (Ward Cunningham)
Patient Appointment
10:00 am Jan 4, 2014 – 11:00 am Jan 4, 2014

Staff Meeting
2:00 pm Feb 1, 2014 – 3:15 pm Feb 1, 2014
public class DateTimeRange
{
public DateTimeRange(DateTime start, DateTime end)
{
Start=start;
End=end;
}
public DateTime Start { get; private set; }
public DateTime End { get; private set; }
…
}
It may surprise you to learn that we should strive
to model using Value Objects instead of Entities
wherever possible. Even when a domain concept
must be modeled as an Entity, the Entity’s design
should be biased toward serving as
a value container rather than a child Entity
container.

—Vaughn Vernon
Implementing Domain Driven Design
Our DateTimeRange Value Object
Team Exercise
Pick same Bounded Context you used for aggregate root
What behaviors need to happen within there
Can you justify 1:1 relationships or are they better as value objects?
Can you justify bi-directional relationshps or are they better as uni-directional
Model some of the methods
 Resources
§ Domain-Driven Design Fundamentals on Pluralsight bit.ly/PS-DDD
§ All of my Pluralsight courses: pluralsight.com/author/julie-lerman
§ Domain-Driven Design, Eric Evans amzn.to/1kstiRg
§ Implementing Domain-Driven Design, Vaughn Vernon amzn.to/1dgYRY3
§ Domain Modeling with Entity Framework Scorecard, Jimmy Bogard, bit.ly/1x925bu
§ Coding for Domain-Driven Design: Tips for Data-Focused Devs (3 Parts)
MSDN Magazine, Aug, Sept& Oct 2013 bit.ly/15xMlDL
§ CQRS Journey from MS Patterns & Practices: bit.ly/cqrsjourney
§ A Pattern for Sharing Data Across Domain-Driven Design Bounded Contexts (Part 1&2)
MSDN Magazine, Oct & Dec 2014: bit.ly/DataPoints_Dec2014
§ Entity Framework Model Partitioning in Domain-Driven Design Bounded Contexts
TechEd Europe 2014: bit.ly/TEE2014_EFDDD