Domain-Driven Design is an approach to modelling business complexity explicitly in your software. This deck of slides runs through the key concepts focusing on both the strategic and tactical aspects of DDD.
10. Let’s Talk About Design…
▪ Do you do it?
▪ Big-Design-Up-Front vs Emergent Design
▪ “Working software over comprehensive documentation”
[Agile Manifesto]
▪ “Continuous attention to technical excellence and good
design enhances agility”
[Principles behind the Agile Manifesto]
▪ While we must acknowledge emergence in design and
system development, a little planning can avoid much
waste
[James Coplien, Lean Architecture]
15. What Is Domain-Driven Design?
1. Focus on the core complexity and opportunity
in the domain
2. Explore models in a collaboration of domain
experts and software experts
3. Write software that expresses those models
explicitly
4. Speak a ubiquitous language within a bounded
context
19. The Problem You’re Trying to Solve
▪ Complexity inherent in software
▪ Essential & Accidental complexity
▪ “That’s not what I meant” [An End User]
20. Definitions…
Problem Domain
▪ A sphere of knowledge, influence, or
activity
▪ The subject area to which the user
applies a program
21. Language
▪ The primary cause of misunderstanding between business &
development teams
▪ Agree and define key conceptsprocessesactors – a shared
vocabulary
▪ Avoid translations
▪ Language is reflected in code
▪ Who?
– Domain Expert (not a Product Owner)
– Development Team
22. Definitions…
Ubiquitous Language
▪ A language structured around the domain
model and used by all team members
within a bounded context to connect all
the activities of the team with the
software
23. Context
▪ Language has a meaning within a context
▪ A Model only has meaning within a context
▪ One Model to rule them all!
▪ Systems serve different user communities
▪ Define the context within which a model applies
– Library Loans
▪ Borrower of a Book
– Library Fines
▪ Member of a Library
24. Definitions…
Bounded Context
▪ A description of a boundary (typically a
subsystem, or the work of a particular
team) within which a particular model is
defined and applicable
25. Modelling
▪ Start with the key concepts in your problem domain
▪ Explore the interactions between these conceptsclasses
▪ Domain Model expressed as an Object Model
▪ Turn key concepts into pertinent classes
▪ Useful models not necessarily realistic
▪ Key: Domain-centric model not Data-centric
26.
27.
28.
29.
30.
31.
32. Definitions…
Model
▪ A system of abstractions that describes
selected aspects of a domain and can be
used to solve problems related to that
domain
Domain Model
▪ An object model of the domain that
incorporates both behaviour and data
33. Our Problem Domain
▪ As a Purchaser I want to be able to request to purchase goods
for independent depots So that I can purchase goods on behalf
of each specific business
▪ As a Purchaser I want to be able to request to purchase goods
that are required for multiple depots So that I can reduce the
amount of time taken to raise purchase orders required for each
depot
▪ As a Manager I want to be able to approve or reject a purchase
request So that we can follow the defined business approval
process
▪ As a Purchaser I want to be able to self-approve an order with
my self-approval limit So that I can purchase items which
require no approval
39. The core domain is the part of
the domain most closely
associated with the strategy of
the company
Core Domain
40. Purpose Alignment Model
MarketDifferentiation
Mission Critical
Does anyone care?
Invest
Parity
Partner
Partner – Do we need
to take this on? Find
a partner
Parity – Achieve and
maintain parity
Invest – Excel and
innovate here, support
USP
Core Domain
Supporting
Sub-Domain
Generic
Sub-Domain
41.
42.
43. Entities
▪ An individual “thing”
▪ Has an identity
▪ Has a life
▪ Mutable
▪ Equality comparison using identity
44. Value Objects
▪ “Primitive Obsession”
▪ Doesn’t have an identity
▪ Equality comparison using properties
▪ Immutable
45. A Word About Immutability
▪ More Immutable structures = betterreliable code
▪ Type safety
▪ Side-effect free
▪ Try to move behavioural responsibilities into Value Objects
▪ Keep management of state in the Entity
46.
47.
48.
49. Definitions…
Entities
▪ Objects that have a distinct identity
that runs through time and different
representations
Value Objects
▪ A small simple object, like money or a
date range, whose equality isn't based on
identity
51. Domain Services
▪ Sometimes, it just isn’t a thing
▪ First class citizens so name is part of Ubiquitous Language
▪ Exposed as a service
▪ A stateless operation
▪ Examples:
– LoanAnItem
– PlaceReservation
▪ Not an Application Service
– IEmailSender
– These depend on Infrastructure
52. Domain Events
▪ Something happened that the domain expert cares about
▪ First class citizens so name is part of Ubiquitous Language
▪ Named in the past tense e.g. ItemWasLoanedEvent
▪ Immutable – a record of something in the past
53.
54. Definitions…
Domain Service
▪ A processtransformation in the domain
that is not a natural responsibility of an
entity or a value object
Domain Events
▪ A full-fledged part of the domain model, a
representation of something that happened
in the domain
55. Aggregates
▪ Collection of Entities and Value Objects treated as a conceptual
whole
▪ Root Entity is the Aggregate’s conceptual name
▪ Business defines the invariants
▪ External references are restricted to the root only
▪ Smaller the better
▪ Consistency:
– Logically consistent within an Aggregate via transaction
– Eventually consistent across Aggregates via propagating updates async
▪ Repository used to load and save an Aggregate
65. Event Storming
▪ Take one big room with lots of clear surfaces
▪ Add Domain Experts and Developers
▪ Give them lots of sticky notes & sharpies (trust me you’ll
need lots)
▪ And get them to…talk?
73. In Summary
▪ Knowing when to use it
▪ Domain centric modelling not data centric
▪ Work with your Domain Experts
▪ Give OO Design another chance
▪ Use Value Objects
▪ Do some f@*?ing design