Public session given about DDD

1. Domain Driven
Design
Tim Mahy
timm@infosupport.com

2. Content
Why ? Patterns (demo)
What ? – Modules
Where ? – The domain objects
– Aggregates
Fundamentals
– Repositories
– The domain
– Factories
– The model
– Specification
– The domain model
– Anti corruption layer
– The ubiquitous language
– The bounded context
Best practices

3. Warning

4. Why ?
The critical complexity of
most software projects
is in understanding the
business domain itself.

5. What ?
Domain Driven design is not a technology or a
methodology.
It’s a way of thinking and a set of
priorities, aimed at accelerating software
projects that have to deal with complicated
domains

6. What ?
Guidance upon a proven technique
– Patterns to keep domain consistent and clean
– Strategies on development responsibility and
integrity
– Principles & practices for the development
process

7. Where ?
High business complexity
Works well for business services inside a SOA

8. The fundamentals
The domain
The model
The domain model
The ubiquitous language
The bounded context

9. The domain
A sphere of knowledge, influence, or activity.
The subject area to which the user applies a
program is the domain of the software.

10. The model
A system of abstractions
that describes selected
aspects of a domain
and can be used to solve
problems related to that domain.

11. The domain model
What needs to be build
Distilled knowledge about the domain
– For the scope of the project
– Consists of a language that is spoken by the whole
team AND the business!

12. The domain model
The model and the heart of the design shape
each other
– They are linked
– Understanding the model allows you to interpret
the code

13. The ubiquitous language
Common language between IT and business
– Avoid miscommunication
– Based upon a shared conceptual model
– Close to domain experts & developers
– Free of misconceptions or contradictions
The language of the team
– Accept and learn together
– Refine understanding over time
– Iron out misconceptions and contradictions
– To ensure that all members have the same
understanding of the words used over time

14. The bounded context
One model to rule them all is a non cost-
effective dream
Create boundaries based upon the
context, the model will only be valid inside
this boundaries
Context map to model relationships between
multiple models
Conceptual splinters indicate different model
– Duplicate concepts
– False cognates

15. Knowledge rich design
It’s more than ‘finding nouns’
Not only about entities but also about rules &
constraints
Implicit concepts should be explicit
Knowledge in the design is a developers best
documentation
Supple design ready for refactoring

16. The essence
Seperate
– Business logic
– Infrastructure

17. The patterns
Modules
The domain objects
– Entities
– Value types
– Services
Aggregates
Repositories
Factories
Specification
Anti corruption layer

18. Modules
Functional partitions inside a domain model
Should be part of the ubiquitous language
Example:
– Reference Data
• Logistics
• Procurement
• Organisation

19. The domain objects
Entities
Value objects
Services

20. The domain objects
Entities
– Data & behavior
– Not your persistance entities (no DTO)
– Functional identity

21. The domain objects
Value objects
– Value = combination of all values
– Have no identity
Try to make
– Immutable
– Copied when exposed on a client so that the client
can hold on to them (<> entities)

22. The domain objects
Services
– Encapsulate business logic
– Cross entity logic
– Correspond to verbs in the ubiquitous language
– Stateless
Try to limit

23. Aggregates
Combination of entities & value objects
One entity is ‘root’ of the aggregate
Ensures consistent state & data integrity
Root entity is navigational start for other data
(via associations)

24. Aggregates
Client code cannot make changes to parts of
the aggregate unless it uses methods on the
aggregate root.
Entities and value objects in an aggregate can
only hold references to other aggregate roots.

25. Factories
Build up aggregates
(Abstract) Factory pattern
Not always needed
Mostly with a fluent API interface
May break encapsulation
Must ensure atomic creation & invariants
Think of identity creation

26. Repositories
Exposes query possibilities in an in-memory
style database of root aggregates
Interface = model
Implementation = infrastructure
Responsible for UOW, Change Tracking…

27. Specification
Place business rules inside predicate objects
Can be used as predicates to factory or
repositories
Can be used to evaluate conditions

28. Specification

29. Specification
If ( customer.NumberOfOrders > 100 && customer.NumberOfDelayedPayment == 0)
{
…..
}

If( new ThrustedCustomer().IsSatifiedBy( customer ))
{
…..
}

If( new ThrustedCustomer().Or( new VeryRichCustomer() ).IsSatifiedBy( customer ))
{
…..
}

30. Anti-corruption layer
Bridges the layer to other worlds
Traditional: mapping to bridge
communications
Bridge between different bounded contexts

31. Do
Domain objects can also represent a process
Keep refactoring to keep clean code
customer.Address = new Address( …

customer.MoveToNewAddress( new Address …

32. Do
Work always test first
– Enhances your ‘client’ API
Use terms of the ubiquitous for your
class/interface names
Strive towords command query responsibility
seggregation to divide operations
Use code contracts
Split functional keys from entities
Make generic value types

33. Do
Try to write BDD tests:
– When
– Given
– Then

34. Do
Implement cohesive mechanisms
– Generic: Time slicing, Graph traversal, History
– Seperate framework
– Try to go declarative
Don’t be afraid of generic subdomains
– Reference data not specific to the problem
domain
Segregate the core from the less important
parts
Abstract core?

35. Do
Apply SOLID principles very strict
newStatus = 3; // Gold
Customer.Update(newStatus, null);
Customer.UpgradeToGoldStatus();

36. Do
Closure of operations
Pigment red = new Pigment();
Pigment blue = new Pigment();
Pigment purple= red.Mix(blue);

37. Do
Declarative programming is a programming style where the
specification becomes executable
– Either by an interpreted language like a DSL or runtime code
generation
• This technique has a lot of merits
• But can impose some risks as well
– Many of the benefits of a declarative design can be reached as well by
combining
• intention-revealing interfaces, side effect-free functions, conceptual contours and
closure of operations
• A fully implemented specification pattern:
var isAllowedToDrive = IsOlderThan(18) & DoesNotDrink();
• Or a fluent interface
c = new CustomerBuilder()
.AsGoldCustomer()
.WithInitialBalanceOf(100.Euros());

38. Don’t
Do only some of the patterns
Start without reading

39. Questions

40. CQRS
Command
Query
Responsibility
Seggregation

42. UI DataStore
Queries
Subscribe
UI Commands
EventBus
Business Logic Publish
Truth (optional)