Short introduction to Domain Driven analysis and design (DDD)

1. Domain Driven Design
Analysis and Design
Jeppe Cramon - @jeppec
Cloud Create ApS

2. @jeppec
"I consider 'getting the boundaries
right' the single design decision
with the most significant impact
over the entire life of a software
project."
@ziobrando

3. @jeppec 3

4. @jeppec
This highly depends on
• How likely are things to change
• And what parts that change together

5. Classic domain analysis

6. @jeppec
Result is often fragmented domain logic
Focus on Nouns (Entities)
and retrofit Verbs later

7. @jeppec
Customer
CustomerId
FirstName
LastName
Email
…
Order
OrderId
Total
DeliveryAddress
Status
…
OrderLine
Quantity
Product
ProductId
Name
Images
Price
Others have bought

8. @jeppec
If we primarily model around nouns/entities
we can easily violate the
Single Responsibility Principle
Where a change to requirements
is likely to require changes
to multiple entity classes

9. @jeppec
Business introduces new rule
Product price depends on Customer Status

10. @jeppec
Customer
CustomerId
FirstName
LastName
Email
Status
…
Order
OrderId
Total
DeliveryAddress
Status
…
OrderLine
Quantity
Product
ProductId
Name
Description
Images
Price
Others have bought
What
now?

11. @jeppec
Jim Coplien

12. @jeppec
Most applications are built with CRUD as
the main paradigm
Intention gets lost

13. @jeppec
We need to shift focus from pure data
towards intent and process automation
This means a change from CRUD style application design,
where the process was implicit and stored in the minds of
the users
First I need to
enter the
employee in
this screen
Then I need to
press a button in
the user system
so they’re
properly created
And the I need
to add their
access card to
this screen and
press Activate

14. @jeppec
Task-based/Inductive UI
• Traditional CRUD UI is what I would call a WHAT UI
• Task based UI’s focuses on HOW the user wants to
use the application
• Guides users through the work process
• The UI becomes an intrinsic part of the design
• The UI design directly affects our commands and
thereby our transactional boundaries

15. @jeppec
We need to capture User Intent at the UI
CRUD style
Task based style
Intent

16. @jeppec
Capturing intent in the form of a Command
A Command is prescriptive of what should happen, and its primary goal is to
capture USER INTENT
A Command
supports a single usecase and
targets a single business object
within a single Transaction
Commands always carry a name in its imperative form:
• AcceptOrder
• ShipOrder
• CancelOrder
• ReimburseCustomer
• Etc.
“A command describes a Task that you want someone
else to carry out for you and where the recipient can
choose to reject the Command”

17. @jeppec
Example
public class OrderService {
public void handle(AcceptOrder cmd) {
orderRepository.add(new Order(cmd.orderId,
cmd.orderLines));
…
}

18. @jeppec
instead of focusing on Nouns!

19. @jeppec
When discussing use cases with Business Experts

20. @jeppec
and what fields that are separate

21. @jeppec

22. @jeppec
Customer
CustomerId
FirstName
LastName
Email
Status
…
Product
ProductId
Name
Description
Images
Price
Decomposing the domain
Customer
FirstName
LastName
Customer
Status
Product
Price
Product
Name
Description

23. @jeppec
But don’t name the piles before you know what they are
This avoids cognitive bias!

24. @jeppec
Give the piles made up names, such as
colors

25. @jeppec
What are the these problem domain piles?

26. @jeppec
Business Capability alignment
“The advantage of business capabilities is their
remarkable level of stability. If we take a typical
insurance organisation, it will likely have sales,
marketing, policy administration, claims
management, risk assessment, billing, payments,
customer service, human resource management, rate
management, document management, channel
management, commissions management,
compliance, IT support and human task management
capabilities. In fact, any insurance organisation will
very likely have many of these capabilities.”
See http://bill-poole.blogspot.dk/2008/07/business-
capabilities.html

27. @jeppec
Business – IT alignment
• We want the Business and IT to speak the same Ubiquitous
language
• Want want our architecture to be aligned with the
business capabilities
• Because these capabilities are stable

28. @jeppec
Many perspectives on data
Online Retail System
Product
Unit Price
Promotional Price
Promotion End Date
Stock Keeping Unit (SKU)
Quantity On Hand (QOH)
Location Code
Price
Quantity Ordered
Name
The lifecycle of the data is VERY important!
Customer
Pricing
Inventory
Sales
Management Reporting

29. @jeppec
Smaller models & clear data ownership
Retail System
Pricing
Product
ProductID
Unit Price
Promotional
Price
…
Pricing
Inventory
Product
ProductID
SKU
QOH
Location Code
…
Inventory
Sales
Product
ProductID
Name
Description
Quantity
Ordered
…
Sales
Shared Entity identity
DDD:
Bounded
Context
Business
Capability
DDD:
Aggregate

30. @jeppec
Aggregates
Invoice
InvoiceLine
*
Account *
What:
• Cluster coherent Entities and Value
Objects, with complex associations into
Aggregates with well defined boundaries.
• Choose one entity to be root and control
access to objects inside the boundary
through the root.
Motivation:
Control invariants and consistency through the aggregate root.
Ensuring consistency & transactional boundaries for Distributed scenarios!
Root
*
*

31. @jeppec
Entities
Motivators:
Objects are defined by identity and NOT by their
attributes.
May have lifecycle, can change form by time and
context (A Person that becomes a father, who becomes
a grand father, etc.)
Focus is on Who and not on what!
Customer
- ID/Social Security Number : Number

32. @jeppec
Value Objects
Customer
- ID/Social Security Number : Number
Address
- street : String
- zipCode : String
1
Motivators:
Objects which Measures,
Quantifies or Describes a thing in
the domain. They’re immutable
and defined by their attributes
(not by their identity) and doesn’t
have a lifecycle.
Focus is on What and not on who!

33. @jeppec
Aggregates refer to each other
by ID
they NEVER use memory pointers, join tables or
remote calls

34. @jeppec
Bounded Contexts and Aggregates
Sales
Product
Customer
customerId
…
Order
orderId
customerId
…
OrderLine
orderId
productId
quantity
timestamp
priceId
ProductCategory
productCategoryId
…
Pricing
Product
productId
productCategoryId
name
tag
...
Product-Price
priceId
productId
normalPrice
discountPeriods
…

35. @jeppec
For more
see
Blog: https://cramonblog.wordpress.com/
Homepage: http://cloudcreate.dk/
Twitter: @jeppec