1.
Applying
Domain-Driven Design to craft
Rich Domain Models
Alexander van Trijffel Templates
Powerpoint
6-2-2014

2.
Agenda
•
•
•
•
•
•
What is a domain model?
Hexagonal Architecture
Ubiquitous Language
When to use Domain-Driven Design?
Adding behavior to the domain model
Value objects

3.
The domain model
Represents business objects, operations and events that reflect the
business processes and are meaningful to the business representatives.
Business rules
‘An Asset Value Correlation multiplier must be applied for exposures with to
Financial Sector Entities with assets of at least $100 bn’
‘In case no Country of Risk is registered in UCI, the C-rating should be ‘No Rating’
Behavior
‘When an assessment is activated, a Global Facility Id is requested from UFI and
assigned to the assessment’
‘When an employee states that he has outside interests, the system accepts stock positions
under certain conditions’

4.
Invariants
‘A confirmed assessment has been calculated’
‘An activated assessment has a GFID’
‘A counterparty has an Wwid’
‘A protection covers at least one debtor’

5.
Hexagonal Architecture

6.
The blue book

7.
DDD on strategic level

8.
Second Page :
"Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor incididunt
ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco
laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident,
sunt in culpa qui officia deserunt mollit anim id est
laborum."
Do we speak the same language?

9.
Ubiquitous
language

10.
DDD on tactical level

11.
Aren’t we
doing DDD
already?
We have
entities…

12.
And our managers/services/*
know all about the logic…
* enter your favorite name for the application service role here

13.
We have a separate business layer

14.
Hello Anemic Domain Model!

15.
When to invest in developing an
ubiquitous language and implementing
a Rich Domain Model?
System type
Domain logic
Complexity
Use cases
DDD
pays off?
CRUD,
Master data, Lookup
Low
Any
No
Simple, Small, Utility
Low
< 30
No
Departmental,
Narrow scoped
Medium
between
30 and 40
Could be
Innovative
Unknown
?
Yes
Enterprise System,
Core system
High
> 40
Yes

16.
Object Oriented Software:
• Encapsulates data and operations in objects
that interact with each other via the object’s interface.
• Applies information hiding; Internal representation
of objects is hidden to clients
Object oriented means that an object manages its state and
guarantees that it is in a legal state at any time.

17.
By applying Object Orientation to the domain model,
the model:
• can ensure that its state is correct at all times
• can hide complexity behind its public interface

18.
Anemic Domain Model example

19.
Applying business rules

20.
What if we have business rules on the client Status as well?
Things get messy quickly…

21.
Empowering the domain:
Encapsulating data and operations in domain objects

22.
Encapsulating domain logic in value objects

23.
Value object – immutable and comparable by its attributes

24.
Model object as Entity or Value Object?
Entity
Value object
Unique
Can have many occurences
Distinguished by identity
Distinguished by attributes
Can be changed
Immutable

25.
Money: Entity or value object?

26.
Value objects examples
Percentage
Probability of Default
Loss Given Default
World Wide Id
Global Facility Id
Rating
Address
Country
Decision
Period
Status

27.
Other tactical DDD patterns to explore:
• Domain Services
• Domain Events
• Aggregates

28.
Summary
Domain-Driven Design is a methodology that provides patterns
for designing rich domains that encapsulate data and behavior.
The investment in developing an ubiquitous language and
implementing a rich domain model pays off for medium to large
applications that implement business rules and processes.
By applying Object Oriented principles to the domain, business
logic is easier to test, understand and extend.

29.
Thanks for
your attention!

30.
Resources
• Domain-Driven Design: Tackling Complexity in the Heart of
Software (Eric Evans)
• Implementing Domain-Driven Design
Vaughn Vernon
• DDD/CQRS mailing list
https://groups.google.com/forum/#!forum/dddcqrs

31.
Backup slides

32.
Empowering the domain:
Constructing objects
What does it mean to be a client in our domain?
• Does a client without a wwid make sense?
• Does our domain even support clients without ratings?
Communicate the intent of a client through the API:

33.
Empowering the domain:
Encapsulated collections
Can the domain object guarantee that the Ratings collection is
valid at all times?
Does it make sense to clear all ratings? Duplicate a rating?

34.
Empowering the domain:
Encapsulated collections
We provide an explicit API to manipulate the collection.