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]:

1. Focused on the core domain
2. Explores models with tied interaction between domain experts and software developers
3. Speak a ubiquitous language within an explicitly bounded context.

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.

• Core Domain. Defines the main set of features and responsibilities that require major efforts to be implemented. It should satisfy the proposed business model.
• Generic Subdomains. Defines parts that include implementation details or other difficulties that make it harder to see the final goal or are not clear to experts, but are necessary for the implementation of the project.

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]:

• Entity - a logically integral object with a set of individual traits that exist during the whole lifecycle
• Value object - an object which describes some aspects of the domain and has no individual existence and self-identity
• Service - an operation suggested as a separate interface, it receives some input and returns some output without state encapsulation
• Module - an entity that encapsulates previous objects

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]:

• Aggregate - a set of objects that are perceived as a whole in terms of data change, which has one root object and boundary. All external objects can refer only to the root object of aggregate, but objects within the boundary can refer in any way.
• Factory - an abstraction that hides objects creation details (how it should be created, which data should be provided)
• Repository - an abstraction that is responsible for storing and returning some object data.

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.

1. An introduction to Domain Drive Desing https://www.methodsandtools.com/archive/archive.php?id=97
2. Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2004
3. Eric Evans, “Domain-Driven Design Reference: Definitions and Pattern Summaries”, 2015
4. Vaughn Vernon, “Implementing Domain-Driven Design”, Feb 6, 2013
5. The Challenges of Applying DDD, https://www.informit.com/articles/article.aspx?p=1944876&seqNum=5
6. Ubiquitous Language и Bounded Context в DDD https://habr.com/ru/post/232881/
7. Domain-Driven Design, My Top 5 Best Practices https://www.codeproject.com/Articles/1131462/Domain-Driven-Design-My-Top-Best-Practices
8. Domain Driven Design на практике https://habr.com/ru/post/334126/
9. Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c
10. Uncovering Hidden Business Rules with DDD Aggregates https://medium.com/nick-tune-tech-strategy-blog/uncovering-hidden-business-rules-with-ddd-aggregates-67fb02abc4b
11. Benefits of Domain Driven Design | And how to use it, https://medium.com/geekculture/benefits-of-domain-driven-design-and-how-to-use-it-58b9b1606c5a