Domain Driven Design (DDD) is an approach to software development that focuses on modeling a domain and implementing software that reflects that model. The domain model is a rigorous organization of knowledge about a domain that is agreed upon by both domain experts and technical people. It is expressed using a ubiquitous language that is consistently used throughout all discussions and documentation about the domain. The domain model forms the basis of the software design, with the implementation expressing the model. Key building blocks of the domain model include entities, value objects, services, and modules. Entities have identity while value objects do not. Services contain application logic without state, and modules break up the domain model into cohesive subdomains.

1. Domain Driven Design - take #2
Mat Holroyd

2. The plan...
Introduction
●
The Domain Model
●
Ubiquitous language
●
Relevance of the model
●
Putting the model to work
●
Building blocks of the domain model
●

3. Introduction
What is domain driven design?
●
Domain
–
Model
–
A collection of ideas
●

4. The domain model
Experts know about a domain
●
The domain model is a 'rigorously organized
●
and selective abstractions of that knowledge'
Artificial
–
Distillation of knowledge
–
Domain experts and technical people both have to
–
learn new terminology

5. The domain model - cont.
Is the model a diagram(s)?
●
Can any type of diagram be part of the model?
●

6. Ubiquitous language
Define one language
●
One with the model
●
Everyone uses it everywhere
●
Design
–
Implementation, but also
–
Any communications (emails)
–
Discussions
–

7. Ubiquitous language - cont.
Advantages?
●
Who decides what term is correct?
●
What's the cost of keeping documents up-to-
●
date?

8. Relevance of the model
Model should form the basis of the design
●
Implementation expresses the model
●
Requires a suitable programming paradigm
–
Understanding come with doing
●

9. Relevance of the model - cont.
What happens if the model has little relevance
●
to the code?
What further understanding of the model does
●
coding give a developer?
Should abstractions be hidden from the user?
●

10. Putting the model to work
How should we transfer model to the code?
●
Model-related objects are only a portion of the
●
code
Layered architecture is the way to go
●
Domain layer is where model logic goes
–
No strict guidelines for other layers
–

11. Putting the model to work - cont.
Keeping model logic in one place is good, but
●
what can cause it to fragment?
Disadvantages of layered architecture?
●

12. Building blocks
Entities
●
Value objects
●
Services
●
Modules
●

13. Building blocks - Entities
Identity matters
●
Attributes may be same as another
●
Using reference alone may not be enough
●
Identity can be formed from attributes
●
Be careful!
–

14. Building blocks – Value Objects
Identity does not matter
●
5, “the cat”, the color 'Red'
●
Should be immutable
●
Can be shared
–
Optimizations (maybe)
–
If mutable, cannot share
●

15. Entities vs Value Objects
Prefer value objects
●
Easier to maintain
–
Easier to optimize
–
Can copy without concern
–

16. Building blocks – Services
Action has no 'home'
●
Contained to a layer
●
Stateless
●
Interface in terms of other domain object
●

17. Building blocks – Modules
Break up a system
●
Can be explained with ubiquitous language
●
High cohesion
–
Low coupling
–
Break up domain layer
●
Not necessary to copy in other layers
–

18. Building blocks - Questions
Entities and value objects – are they for any
●
layer?
What about supporting code, such as lists. Do
●
they fit under the title of entities or value
objects?

19. My thoughts
Side-effect free functions, value
●
objects...sounds like functional programming
Concepts help explain advantages and
●
disadvantages of Ruby-on-Rails and Access
Large parts of infrastructure is written already
–
Not using single model explains why 'those
●
bloody coders did not implement it as they are
supposed to!'