By Dmitriy Butakov (dvbutakov@edu.hse.ru)
Sofware development is a process of creating tools for solving specific problems. The more streamlined the process, the better the output tool or product is. There are a lot of sets of approaches directed to design, architect, develop and test software. One of the most common approaches is the domain-driven design which builds the development process around the problematiсs. Domain-driven design is quite an efficient mechanism, but with a lack of knowledge of how to use it most appropriately, it turns into a tool for the destruction of the project. This essay describes the narrow paths that can arise when introducing DDD into a project.
Before we understand what problems can arise when implementing DDD, let's briefly go over the terminology. First of all, the term “domain-driven design” should be defined and clarified. Domain-driven design is an approach to complex software which is [3]:
A domain represents a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software [3]. To study a wide area of knowledge, an obvious solution is to split the subject area into smaller parts and determine the order of study. Likewise for solving large problem domains, the DDD approach requires determining Core Domain and Generic Subdomains.
After Core Doman and Generic Subdomains are distilled, the Domain Model creation process begins. Domain Model is a sample of distilled knowledge strictly organized by the pursued goals, which has a structure that is understandable for all participants in the process. It should be should directly map on architecture and source code. A model can consist of [3]:
The interaction between them is defined by associations. These objects should be maintained by their lifetime and associations. Maintenance is defined by several architecture templates [3]:
Now, after acquaintance with the terms, in a nutshell, we will try to figure out what challenges arise when introducing DDD.
Eric Evans at the beginning of his “blue book”, which summarizes the set of rules, principles, and methods of the domain-driven design, relates to three examples of different projects which were trying to implement domain-oriented design methodology, but only one project has succeeded. The main reasons for the failure of projects, he says, are the flaw of a domain model, the lack of an all-encompassing (ubiquitous) project language, and the wrong distribution of labor [2]. Vaughn Vernon in “Implementing Domain-Driven Design” confirms the idea that a poorly formulated communication language between developers and experts in the field can significantly complicate the implementation and maintenance of a project. Moreover, he extends these challenges with insufficient participation of experts during the design and development process and changing developers' way of thinking about solutions within the problem domain [4].
The last-mentioned problem flows from the drawback of the ubiquitous language. Why this is so important? Because in addition to the fact that the developer has to understand the subject area, deviation from the unified language forces other developers, as well as experts of the area, to immerse themselves in the area of perception created by the developer himself. This can lead to misunderstandings on both sides and, as a result, lead to failure to fulfill business requirements. Moreover, in the long term, as the project evolves after the initial draft, it takes more time than clearly defining a comprehensive language in the initial stages.
Another challenge that may occur is a badly designed Domain Model. Looking ahead, Problems may arise even oncoming to creating a model, when determining the Core Domain. Adding unnecessary details to the list of objects that interfere with the perception of details can confuse experts and obscure the view.
When creating a model, an incorrectly defined object, or an incorrectly used (or not used at all) template can complicate the process of understanding, implementing, and maintaining the product. For instance, the shortage of Aggregates can add more links, which makes it harder to understand the problem which Domain Model covers and complicate the process of writing code. Continuing the previously mentioned words about the incorrect use of terms, some implementation details can be hidden using Modules, Factories, and Repositories. Too much detail in the model makes it difficult to understand the problem.
Most challenges arise as a result of lack of principles details knowledge of DDD or unwillingness to spend extra resources on design and accelerated obtaining results. A meticulous approach, established through mutual understanding of developers and subject matter experts, as well as knowledge of DDD patterns and adherence to a correctly formulated Domain Model, will avoid many problems when implementing DDD. But it is important to remember that the introduction of DDD into a project is only necessary if it covers or plans to cover a wide area.