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!'
