An Introduction to Domain-Driven Design - Part 2

First Part here - https://hackernoon.com/domain-specific-programming-what-is-it-and-how-to-live-with-it-part-1

It's no secret that applicable models rarely lie on the surface. As awareness and understanding of the subject area grow, unimportant or minor parts are usually found in the model, safely discarded. Ideas may arise that did not come to mind before but now may become the main ones. The processing and assimilation of knowledge is a rather creative and research-intensive process, and it is difficult to say in advance where the studies will lead you. As I said earlier, a common language is something that none of my projects can do without. And the domain model can serve as the basis for its creation.

Model

A set of concepts existing in the head of the customer/project creator and terms that reflect his understanding. To develop a flexible, information-intensive architecture, the team needs to have a rich common language and actively experiment with it, which, unfortunately, rarely happens. I often met groups where analysts and developers spoke completely different languages ​​and did not understand each other. They did their job well, but the systems they produced were closed to expansion and understanding. With the growth of analysts' concepts, it became more and more difficult for programmers to understand what they wanted from them. In a project that has no common language, programmers have to become translators. And due to incorrect translation, the concepts of the model can become clouded - the result will be destructive refactorings. In your daily discussions, the same terminology should be used, embedded in the code (after all, the code is the main thing that is created on the project). You can create a dictionary of a single language - these can be the names of classes and basic operations, the names of constants.

The language, in turn, should be used to describe not only objects but also tasks and even functionality. The same model should provide analysts and developers with a language to interact with each other. The more we use a common language, the easier it is to establish fruitful communication in a team. But the common language is constantly changing and improving. And changes in the language should be understood as changes in the model, which means that developers must make changes to the code, the class diagram, rename them, and change the program's functions. Your analysts should object to terms or structures that are inconvenient or do not convey the essence of the subject area. I will touch on the common language a few more times because I consider it a necessity. Developers must keep track of any ambiguities, as this will damage the architecture. Another critical aspect in the modeling of systems is the modeling by ear.

Unfortunately, not all teams at daily rallies or planings communicate in the same language. And you can hear analysts say one thing and developers another. But one of the best ways to improve the model is to run it in the same language, describe the constructs, and test everything in words. Inaccuracies and inconsistencies will be revealed instantly.

In the process of using a single language during discussions, we improve and rework it. Knowledge is shown from a new side. The more we speak the language, the better we understand it and come to close joint use. It is worth noting that if the domain specialist does not understand the model, something is most likely wrong with this model. Just like a programmer, if the system turns out to be too complex and confusing, then most likely, the development team is doing something wrong. But as soon as analysts and developers begin to use a common language, the movement starts towards a model that can be useful to all parties. Suppose analysts use a common language in their discussions and discussions with developers. In that case, they will quickly discover areas where the model is incorrect, does not fit with the rest of the system, or is completely wrong.

Domain experts can write a use case or, for example, develop acceptance tests using a common language. In the Agile development methodology, requirements usually change during the development process. In the course of this evolution, the common language must also change.

During the development of the project, many diagrams are often drawn at meetings. This is useful because many people perceive information visually. But the trouble comes when a team tries to convey the entire architecture through diagrams and UMLs. Unfortunately, it is almost impossible to bring all the subtleties of the architecture and model on the diagram. There will be many objects on the diagram in a sufficiently large project, and the circuit will become overloaded. Still, at the same time, during the circuit overload, important nuances may not be noticed. Diagrams are visual aids and communication tools that can facilitate the discussion of an issue. And this works best when they contain a minimum number of elements. It is always worth remembering that a model is not a diagram. The diagram is needed to explain the model and for better visual perception.

As I said earlier, oral communication helps to complement and develop the model and code of the program. But sometimes you can't do without written documents. It is necessary that written documentation helps the development of the project and does not hinder it. But this is incredibly difficult. There are several approaches to help you get the correct documentation:

• The documentation should be supplemented by oral discussion.
• The documentation should be proactive and keep up with the process.

Each methodology uses its options for working with documentation. In some, the procedure is proposed to exclude it completely, let the code document everything. But the documentation should not be assigned those tasks that the code copes well with. The documentation should reflect the essence and meaning. The documentation should help you understand the large-scale parts of the project and explain the architecture's meaning.

It is worth noting that the document should actively participate in the work of the project. The easiest way to check this is to trace the relationship between a single language and a document. By setting the documentation task to supplement the code and oral discussions and keeping only what is needed, you can maintain a close relationship between the documentation and the project. A single language and its evolution should help determine the most necessary and active factors for implementing the document.