DDD — Notes from the big blue book. Part 3

Here’s what I’ve cherry-picked from chapters 5 & 6

Chatper 5

• Implementing associations between entities in the design can be difficult
• 3 types of object
• Entities
• Value types
• Services
• Modules are part of the model and should reflect concepts in the domain
• For every traversable association in the model there is a mechanism in the software with the same properties
• Constrain relationships
• 1-to-many is easier than many-to-many
• Ultimate simplification is to remove relationship
• Strip entities down to the most common characteristics
• Gear them up to be totally about identity
• Don’t give identity to value types
• Parameters and results of services should be domain objects — e.g. money not decimal
• Don’t let services strip behaviour from entities or value types
• Careful use of domain services is key to keeping domain logic in the domain
• Use well-defined modules to aid comprehension of the logical groupings of the domain
• Modules and entities should co-evolve — ** they are not fixed **
• Don’t let frameworks constrain how the model is chunked

Chapter 6

• Factories and repositories are allowed in the domain
• Aggregate root is responsible for checking invariants
• Root may pass reference of nested entity, but receiving object may not keep the reference
• Delete the root — and the entire aggregate should go at the same time
• Use factories to create entire aggregates as a piece
• Consider a coding standard for factory failures
• A factory can delegate invariant checking to the aggregate — but not always
• Database schema should update to reflect changes in the model