Design Learnings: Domain driven design notes - [2] Communication and the use of language

A domain model can be the core of a common language for a software project. The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight.
Ubiquitous language

Across the linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand.
The indirectness of communication conceals the formation of schisms, different team members use terms differently but don't realise it.
A project faces serious when its language is fractured. Domain experts use their jargon while technical teams have their own.
Translation blunts communication and makes knowledge crunching anaemic
The over head cost of all the translation, plus the risk of misunderstanding is just too high.
The vocabulary of Ubiquitous language includes the name of classes and prominent operations.
Same model should supply the language for the developers and domain experts to talk to each other
Persistent use of Ubiquitous language will force the models weaknesses in open
Use the model as the backbone of the language. Use the same language in diagrams, writing and especially speech
Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words
Recognise that a change in the Ubiquitous language is a change in the model
Developers should watch for ambiguity or inconsistency that will trip up the design
The language carries knowledge in dynamic form

The detachment of speech from other forms of communication is a particularly great loss because we humans have a genius for spoken language
One of the best ways to refine a model is to explore with speech
It is vital that we play around with words and phrases, harnessing our linguistic abilities to the modelling effort
Our brains seem to be somewhat specialised in dealing with complexity in the spoken language
We can exploit out innate talent for grammatical, meaningful language to drive model development
Find easier ways to say what you need to say and then take those new ideas back down to the diagrams and code

Domain expert is assumed to be capable to thinking deeply about his field. If sophisticated domain experts don't understand the model, there is something wrong with the model
The developers and domain experts can informally test the model by walking through scenarios, using the model objects step by step

UML diagrams are good at communicating relationships between objects, and they are fair at showing interactions, but they do not convey the conceptual definition of these objects
Attributes and relationships are only half the story of an object mode. Behaviour on those objects and the constraints on them are not so easily illustrated
Diagrams are means of communication and explanation and they felicitate brainstorming. they serve these ends best if they are minimal.
The vital detail about the design is captured in the code
Always remember that the model is not the diagram

External documents and diagrams do not affect the behaviour of the program so they fall out of sync
Code as a design documents does have its limits. Its behaviour is unambiguous but that does not mean its obvious
Other documents need to illuminate meaning, to give insight into large scale structures

In addition to saving labour, hand drawn documents have the advantage of feeling casual and temporary
Greatest value of the design document is to explain the concepts of the model
By keeping documents minimal and focussing them on complementing code and conversation, documents can stay connected to the project

Still, even when code can mislead, it is closer to the ground that other documents
To communicate effectively, the code must be based on the same language used to write the requirements-the same language that the developers speak with each other and the domain experts

Design Learnings