The developers still do not pay due attention to the concept of design focused on the subject area, although it has existed for some time.
This concept was first developed by Eric Evans in his 2003 book "Domain-Driven Design. Tacking Complexity in the Heart of Software "(in the developer community it is called the" blue book "). The main idea of the book is that a single language should be a fundamental part of the product being created.
Domain-Driven Design is a software development methodology for tackling complex software projects to deliver an end-product that meets the goals of the organization.
There are several common terms that are useful in describing and discussing DDD practice:
1. The fundamental concept is ubiquitous language
It promotes transparent communication between project participants. The development team uses this language in all interactions, from SOW to code. A single language is structured around the domain model.
2. Domain model
Is a result of DDD. The conceptual model is often a dictionary and key concepts of problems from the subject area. Describes individual aspects of the subject area and can be used to solve problems related to this subject area.
3. The context
The situation where the word and statement that determines its meaning appears. Model statements can only be understood by context.
4. Bounded context
Describes the boundaries of subsystems or the operation of a specific group within which the model is defined and applied.
The main focus of DDD is to understand how to create abstract domain models that can be implemented with a set of technologies. The DDD methodology provides guidance on how to develop models and develop technologies to create a system that meets user needs and is resilient to change in subject areas.
How to use DDD?
The process of Domain Driven Design provides for cooperation between developers and non-developers. Ideally, there should be a common model with common languages, so when people from different areas with different perspectives discuss a solution, they will have a common knowledge base with common concepts.
To apply DDD in practice, developers will have to start from scratch. It will not be possible to partially introduce the DDD concept into your project if the rest of the model is designed in the traditional way. In this case, it will not be possible to satisfy the end result of the user.
Advantages of DDD
Facilitates communication
A single language simplifies communication between technical and non-technical members of the development team.
Improves flexibility
Multi-level and modular design makes it easy to upgrade, modify, and upgrade the product as needed with less unintended consequences.
Efficiency
In the case of close participation of experts in the subject area, the product is more likely to do the work that it must do. That is, it is least likely that it will have functions that no one will use.
User orientation
By keeping the subject area at the center of the design process, the result is a product that meets the needs of the users.
Disadvantages of DDD
Reliable knowledge of the subject area is needed
All product development will be in vain if the team does not have at least one expert in the subject area, who knows exactly all its subtleties. And developers will need to spend a lot of time with this expert to fully understand the subject area.
Not suitable for high-tech projects
If the project is technically difficult for a subject matter expert to understand, then in the future all team members will have problems.
As soon as the development team studies DDD and begins to apply its philosophy, the perception of the software will change. This is because the DDD concept is a very powerful and effective approach to developing projects with complex business logic. To do this, all participants must have a high degree of involvement in the project, readiness and the ability to study the subject area deeply enough and find a common language.
Literature for the study of DDD
There are not many educational materials on this topic. The whole theory is described in only a few books, and they are very difficult to perceive.
Many who worked with the DDD concept advise you to start researching the DDD information in the original and in the order in which they are arranged below:
1. Vaughn Vernon. Implementing Domain-Driven Design.
2. Eric Evans. Domain-Driven Design. Tacking Complexity in the Heart of Software.
3. Vaughn Vernon. Domain-Driven Design. Distilled.