CHAPTER 2- The Ubiquitous Language
It is completely vital to build up a model of the domain by having the domain experts work with the domain analyst. However this approach has some underlying challenges due to a essential communication hindrance. The developers have their minds brimming with classes, methods, patterns, algorithms, and tend to continuously make a match between a real life concept and a programming substitute. While the domain experts talk about a model in terms of more of non-technical terms and language. This creates a language barrier between the experts and developers which results in a gap between the original model and the developed model.
Therefore a language is needed which ensures a fruitful communication between domain experts and developers to develop a model perfectly. Such a language is an Ubiquitous language.
Ubiquitous Language:
This is a language which has to be developed to connect all parts of the design. The entire design code, classes, methods should be based on this domain specific Ubiquitous language only.
When change happens at a part in the language it must be reflected to the model in real time. This Ubiquitous language is shared by the entire team including domain experts, analyst, developers, testers.
Creating Ubiquitous language:
Some individuals prefer UML adequate to assemble a model upon.
It is a tool to record key ideas as classes, and to express connections between them. Be that as it may, the classes conduct and the requirements are not all that effortlessly communicated. For that UML resorts to content put as notes into the chart.
So UML can't pass on two essential parts of a model: the significance of the ideas it speaks to and what the items should do.
We can add different tools too to defeat this trouble. We can draw graphs of sub models and add content to it also.
Documents can be utilized also to substitute the Ubiquitous language.
Be careful about long archives or documents. It requires a considerable measure of investment to think of them, and they may get to be distinctly out of date before they are done. The records must be in a state of harmony with the model. Old records, utilizing the wrong dialect, and not mirroring the model are not helpful at all.
It is likewise conceivable to communicate using code.
Elegantly composed code can be exceptionally informative. Despite the fact that the conduct communicated by a technique is clear, is the method name as clear as its body? and so alternate variables as well. Code, which practically makes the best choice, does not really express the proper thing. Composing a model in code is exceptionally troublesome.
Important Chapters in Domain Driven Design
