Domain Driven Design - take #2Mat Holroyd

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

Introduction● What is domain driven design?

– Domain– Model

● A collection of ideas

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

The domain model - cont.● Is the model a diagram(s)?

● Can any type of diagram be part of the model?

Ubiquitous language● Define one language

● One with the model

● Everyone uses it everywhere– Design– Implementation, but also– Any communications (emails)– Discussions

Ubiquitous language - cont.● Advantages?

● Who decides what term is correct?

● What's the cost of keeping documents up-to-date?

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

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?

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

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?

Building blocks● Entities

● Value objects

● Services

● Modules

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!

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

Entities vs Value Objects● Prefer value objects

– Easier to maintain– Easier to optimize– Can copy without concern

Building blocks – Services● Action has no 'home'

● Contained to a layer

● Stateless

● Interface in terms of other domain object

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

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?

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