Slide 1
Slide 1 text
Introduction to the
Domain-Driven Design tactical
patterns
with outside-in Test-Driven Development
Pim Smeets, João Rosa
@p_smeets @joaoasrosa
Slide 2
Slide 2 text
Introduction to the
Domain-Driven Design tactical
patterns
with outside-in Test-Driven Development
Pim Smeets, João Rosa
@p_smeets @joaoasrosa
Slide 3
Slide 3 text
3
@p_smeets @joaoasrosa
● Who are we?
● Why this webinar
● What we want to do today
Slide 4
Slide 4 text
4
@p_smeets @joaoasrosa
We will show how to:
- Implement DDD tactical patterns with outside-in
TDD
- Make your codebase as explicit as possible
- Test behaviour, not implementation
- Change your codebase without breaking tests
with a live coding session!
Agenda
Slide 5
Slide 5 text
5
Our domain
Domain objects:
● Entity
● Value Object
● Aggregate
● Domain Service
● Repository
Slide 6
Slide 6 text
6
@p_smeets @joaoasrosa
Getting started with Code
Probing
Slide 7
Slide 7 text
7
Scenario - Example Mapping
Slide 8
Slide 8 text
8
Model
Slide 9
Slide 9 text
9
Code Probe
Domain objects:
● Entity
● Value Object
● Aggregate
● Domain Service
● Repository
Slide 10
Slide 10 text
10
@p_smeets @joaoasrosa
Live coding
Existing domain - model partially implemented
Refactor;
● Ensure that we correctly applied our tactical patterns
● Remove unused tests
Extend; adding a new aggregate
● Outside-in TDD
Change; touch existing code
● Where to make the change?
● How to do it safely?
Slide 11
Slide 11 text
11
@p_smeets @joaoasrosa
Live coding
Slide 12
Slide 12 text
12
@p_smeets @joaoasrosa
Entity & Value Objects
Entity - who?
● Identified by its identity rather than attributes
● Identity remains fixed throughout lifecycle, attributes may change
● Primarily responsible for identity - not behaviour
Value Object - what?
● Used as descriptors for other domain objects
● Can only be identified by its characteristics
● Identity not required because characteristics only have meaning in a particular context
● Immutable; cannot have state changing methods
● Primarily responsible for behaviour - not identity
Slide 13
Slide 13 text
13
@p_smeets @joaoasrosa
Aggregates
An aggregate:
● Protects business invariance by forming a transactional consistency boundary
● Favors a single traversal direction, as opposed to bidirectional relationships
● Group domain objects so you can refer to the as a single concept
● Is written to / read from persistent storage as a whole through a repository; this can lead to
eventual consistency
The aggregate root:
● Is the gateway into an aggregate
● Is always an entity, without a parent entity
● Must be referred to be ID instead of object reference
Slide 14
Slide 14 text
14
@p_smeets @joaoasrosa
Repository
A repository
● Is an intermediate layer between the domain model and the data layer in your infrastructure
● Is defined as an interface in your domain
● Implemented in your infrastructure
● Supplies your domain with the data that it needs to operate
Slide 15
Slide 15 text
15
@p_smeets @joaoasrosa
Domain Service
A domain service can:
● Encapsulate business policies and processes or
● Act as a contract where the implementation relies on the infrastructure
It:
● Acts as a linking pin between multiple entities / aggregates
● Is always stateless
● Encapsulates UL and concepts that are important to the domain
● Often orchestrates multiple entities or domain objects
You use it when:
● The concept exists in the problem domain
● Your domain model at least interfaces with the problem