modelling a complex domain with domain-driven design
TRANSCRIPT
Modelling a complex domain with Domain-Driven Design
@NaeemSarfraz#DDDesign #LeedsSharp
Can you tell me what is the problem you’re trying to solve?
Is it possible to write code that reflects the problem domain?
Could you deduce the original requirements from your code?
Who am I?
Solutions Architect @ Barrett Steel
10+ years .NET Developer
Learn(new Things()).Like()
Play(Archery).Add(Horseriding).Like()
@NaeemSarfraz
http://naeemsarfraz.net
Silver Bullet Warning
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]
Domain-Driven Design
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
Correct Hashtag: #DDDesign
!#DDD
The Problem You’re Trying to Solve
▪ Complexity inherent in software
▪ Essential & Accidental complexity
▪ “That’s not what I meant” [An End User]
Definitions…
Problem Domain
▪ A sphere of knowledge, influence, or activity
▪ The subject area to which the user applies a program
Language
▪ The primary cause of misunderstanding between business & development teams
▪ Agree and define key concepts\processes\actors – a shared vocabulary
▪ Avoid translations
▪ Language is reflected in code
▪ Who?
– Domain Expert (not a Product Owner)
– Development Team
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
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
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
Modelling
▪ Start with the key concepts in your problem domain
▪ Explore the interactions between these concepts\classes
▪ 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
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
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
What are the Key Concepts?
The core domain is the part of the domain most closely associated with the strategy of the company
Core Domain
Purpose Alignment Model
Market Differentiation
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
Entities
▪ An individual “thing”
▪ Has an identity
▪ Has a life
▪ Mutable
▪ Equality comparison using identity
Value Objects
▪ “Primitive Obsession”
▪ Doesn’t have an identity
▪ Equality comparison using properties
▪ Immutable
A Word About Immutability
▪ More Immutable structures = better\reliable code
▪ Type safety
▪ Side-effect free
▪ Try to move behavioural responsibilities into Value Objects
▪ Keep management of state in the Entity
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
Beware of Anti-Patterns
▪ Anaemic Domain Model
▪ The Leaky Model
▪ Partially Initialised Entities
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
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
Definitions…
Domain Service
▪ A process\transformation 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
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
Definitions…
Aggregate
▪ A cluster of associated objects that are treated as a unit for the purpose of data changes
Presentation Layer
Business Layer
Data Access Layer
Data Storage Layer
Loans Context
Fines Context
Loan
Aggregate
Account
Aggregate
Book
Returned
Visual Studio time…
Model Exploration Whirlpool
▪ Start with a reference scenario
▪ Propose a model
▪ Code probe
▪ Repeat
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?
Time
Book
ReservedBook
Returned
Member
Pays
Money
Book
Loaned Fine Paid
Lorem
Ipsum
Dolored
Lorem
Ipsum
Dolored
Lorem
Ipsum
Dolored
Lorem
Ipsum
Dolored
Lorem
Ipsum
Dolored
Can we
pay
later?
Lorem
Ipsum
Dolored
What’s if
the book
is never
available
Places
Reservation
Can we
pay half
the fine?
In Summary
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
Follow up…
Events
▪ DDD Europe 2017 - Amsterdam
– https://dddeurope.com/2017
▪ DDDx 2017 – London
– https://skillsmatter.com
Pluralsight
▪ Domain-Driven Design in Practise
▪ Domain-Driven Design Fundamentals