Domain Driven Design Chapter 2 Notes

Domain Driven Design

A model is a set of concepts built-up in the heads of people working on the project
The domain affects how people communicate
- The semantics of a language
- Precise language referring to specific concepts
- Outsiders may just hear jargon whereas domain experts understand all the terminology
Need a common language for everyone to understand
- Commonly used coding patterns
- Terms for rules
- Names of modules and prominent operations
Domain experts need to adjust their language depending on who they talk to

Ex. 1, the domain expert doesn't understand the vague terminology because the domain model is weak
Ex. 2, there's a more developed domain model which is more specific, this creates terminology that is less abstract than just "rows" and "tables"

Begin exploring by talking about the potential model through speech
The initial model will be incomplete and rough around the edges
Apply different ways of thinking through speech and diagrams
Define new terminology and find easier ways to communicate your ideas and incorporate them into the model

Developers and domain experts may not share the same language as they are concerned with different components
However, domain experts need to understand the core domain otherwise developers don't know if they are going in the right direction
Informally test by walking through scenarios and testing if the behaviour is correct

UML diagrams for communicating relationships between components
- Not good at constraints and assertions
- Provide a high level overview, not concerned about concrete details
- Can add text to complement

Documents are typically forgotten as a project moves on, they should be updated and should complement the code
Should cover commonly terminology
Should navigate details of the code but not regurgitate the code
Explain concepts of the model and intended use