Domain Driven Design Chapter 2 Summary

Chapter 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."
• "To make most effective use of a model, it needs to pervade every medium of communication."
• Ubiquitous Language
• Domain experts:
• have limited understanding of the technical jargon of software development.
• use the jargon of their field.
• Developers:
• may understand and discuss the system in descriptive, functional terms, devoid of the meaning carried by the experts' language.
• may create abstractions that support their design, but are not understood by the domain experts.
• This causes a linguistic divide, where domain experts vaguely describe what they want, and developers vaguely understand.
• With conscious effort, the domain model can provide the backbone of a common language.
• Ubiquitous language:
• includes names of classes and prominent operations.
• includes terms to discuss rules that have been made explicit in the model.
• is supplemented with terms from high-level organizing principles imposed on the model.
• is enriched with the names of patterns the team commonly applies to the domain model.
• meanings of words and phrases echo the semantics of the model.
• "The more pervasively the language is used, the more smoothly understanding will flow."
• Points to apply:
• Use the model as the backbone of a language.
• Commit the team to exercise that language in all communication, including:
• Code
• Diagrams
• Writing
• Speech (especially)
• Iron out difficulties by experimenting with alternative expressions, which reflect alternative models.
• Then refactor the code to conform to the new model.
• Resolve confusion over terms in conversation.
• Recognize that a change to the ubiquitous language is a change to the model.
• Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding.
• Developers should watch for ambiguity or inconsistency that will trip up design.
• Example: Working Out a Cargo Router
• Gives two examples of a conversation between a developer and a domain expert, one where the developer primarily uses software technical terms, and one where the code reflects a model and a shared language, demonstrating the conciseness of the conversation.
• Modeling Out Loud
• "One of the best ways to refine a model is to explore with speech, trying out loud various constructs from possible model variations. Rough edges are easy to hear."
• As an addendum to the ubiquitous language pattern:
• Play with the model as you talk about the system.
• Describe scenarios out loud using the elements and interactions of the model, combining concepts in ways allowed by the model.
• Find easier ways to say what you need to say, and then take those ideas back down to the diagrams and the code.
• One Team, One Language
• "Technical people often feel the need to "shield" the business experts from the domain model. [...] Of course there are technical components of the design that may not concern the domain experts, but the core of the model had better interest them. Too abstract? Then how do you know the abstractions are sound? Do you understand the domain as deeply as they do? [...] [A] domain expert is assumed to be capable of thinking somewhat deeply about his or her field. If sophisticated domain experts don't understand the model, there is something wrong with the model."
• "The domain experts can use the language of the model in writing use cases, and can work even more directly with the model by specifying acceptance tests."
• "Multiplicity of languages is often necessary, but the linguistic division should never be between the domain experts and the developers."
• Documents and Diagrams
• "Simple, informal UML diagrams can anchor a discussion. Sketch a diagram of three to five objects central to the issue at hand, and everyone can stay focused."
• "The trouble comes when people feel compelled to convey the whole model or design through UML. A lot of object model diagrams are too complete and, simultaneously, leave too much out."
• People feel it needs to show all the detail they will code.
• With all that detail, no one can see the forest for the trees.
• Yet in spite of that detail, important information is still missing.
• Behavior and constraints are not so easily illustrated.
• This falls to supplemental text or conversation
• "Diagrams are a means of communication and explanation, and the facilitate brainstorming. They serve these ends best if they are minimal."
• "The vital detail about the design is captured in the code."
• Written Design Documents
• "[M]aking written documents that actually help the team produce good software is a challenge."
• "Once a document takes on a persistent form, it often loses its connection with the flow of the project. It is left behind by the evolution of the code, or by the evolution of the language of the project."
• Two general guidelines for evaluating a document:
• Documents Should Complement Code and Speech
• "A document shouldn't try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior."
• "Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements." 
• "Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept."
• Documents Should Work for a Living and Stay Current
• "A document must be involved in project activities."
• If a document in not read or found to be compelling or is being left behind, then the document is not relevant or not important enough to update.
• "It could be safely archived as history, but left active it could create confusion and hurt the project. And if a document isn't playing an important role, keeping it up to date through sheer will and discipline wastes effort."
• Executable Bedrock
• Well written code can be very communicative, but to ensure that it communicates the correct message takes effort.
• The behavior of the code is indisputable, but that does not mean that what the written code says reflects this behavior. Misnamed or unclear class, function, and variable names can pollute the meaning.
• "It takes fastidiousness to write code that doesn't just do the right thing but also says the right thing."
• "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 with domain experts."
• Explanatory Models
• "The model that drives the design is one view of the domain, but it may aid learning to have other views, used only as educational tool, to communicate general knowledge of the domain."
• "One particular reason that other models are needed is scope. The technical model that drives the software development process must be strictly pared down to the necessary minimum to fulfill its functions. An explanatory model can include aspects of the domain that provide context that clarifies the more narrowly scoped model."
• Example: Shipping Operations and Routes
• The example starts by showing a UML diagram of part of the model. While accurate the meaning isn't readily transparent.
• Next a more free form diagram following a timeline is given, which much more clearly conveys some ideas that were originally shown in the UML diagram.
• Together they are easier to understand than either view alone.