Model is a set of concepts built up in the heads of people who work on the project
Terms and relationships reflect model insight
Semantics of a language tailored to the domain
Precise enough for technical development
Domain experts talk in jargon of their field
Developes talk in jargon of software development without the meaning carried by the domain
Developers struggle to understand domain experts
Have to translate which muddles concepts
Need a common language that everyone understands
Ubiquitous language
Includes names of classes and prominent operations
Terms to discuss rules which have been made explicit in the model
High level organization
Names of patterns the team commonly applies to the model
Should also be used to describe tasks and functionality
As gaps are found in the language new words enter the discussion
Changes to the language will be recognized as changes in the model
Domain experts need to speak outside the scope of the language to give context
Within the scope they should use the language
Model is the backbone of the language
Team should use the language in every form of communication, code, diagrams
Try different expressions which reflect alternate models
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding
This assumes 1 domain, later chapters deal with multiple
Cargo router
The first discussion uses "delete the rows", "boolean", "shipment table", etc.. which the domain expert doesn't understand.
The domain model is weak, with only a Routing Service and a table.
In contrast, the second example has a more developed domain model which adds Cargo, Route specification, Itinerary, and Leg
In the second example these terms are used to discuss the domain explicitly instead of through abstract concepts like rows and tables
Modelling out loud
Can explore the model with speech
Model will start out awkward and incomplete
Rough edges of the model where it's underdeveloped can be heard by verbose speech - concepts needed to explain are missing
Different ways of thinking - speech, visual diagrams - complement each other
Find easier ways to say what you need to say and incorporate into the model
One team one language
There may be technical components of the design that do not concern the domain experts, but they need to understand the core of the domain otherwise you don't know if it's correct
Initial design by the domain experts will not use the language, not developed yet
Old documents should be revised as the language develops
When the domain experts use the language they find areas where the model is inadequate or seems wrong
Can informally test model by walking through scenarios
Developers do use technical terminology that domain experts don't need ot understand and vice versa
Extensions to the language - Do not contain alternative vocabularies for concepts in the ubiquitous language
Documents and diagrams
UML is good at communicating relationships between object and fair at describing interactions
Do not convey conceptual definitions
Sketch a diagram of 3 to 5 objects central to the issue, can be changed as people try different thought experiments
Don't try to convey the whole model or design through UML
UML is not good at constraints and assertions
Need supplemental text or conversation
Not good for code generation
Not a model if it contains all the detail
Want a high level overview that's uncluttered and can be worked with
Written design documents
Lose their connection with the flow of the project
Left behind as project evolves
Documents should complement code and speech
Document shouldn't try to do what the code already does
Documents should work for a living and stay current
Explain the concepts of the model
Help navigate details of the code
Give insight into the models intended use
Must be involved in project activities
If terms in the document don't show up in conversations and code the document is not fulfilling it's purpose
Executable bedrock
While code can mislead it is closer to the ground than documentation
Explanatory models
One model should underline implementation, design, and team communication
Separate models for separate purposes is a hazard
Models can also be used to teach about the domain
May have other views of the domain for education
Explanatory model can contain aspects of the domain for context
More communicative style for a particular topic
Generally best to not be object models and to avoid UML