Domain-Driven Design: Why Do Companies Need This Approach, Who Uses It, and What Is Its Essence?

Building software that meets the needs and expectations of businesses and users in a dynamic and ever-changing technological world can be challenging. Software companies gradually require a workable way to make communication between the business and the product team more transparent. The domain-driven design (DDD) approach helps to solve this problem by fostering a profound understanding of the subject matter and continuous collaboration between developers and business experts. In fact, developers gain a more in-depth understanding of the underlying domain and business rules through constant communication. At the same time, stakeholders gain a better understanding of technical capabilities and constraints.

For example, Standish Group’s analysis of 100 projects found that 70% of rework was due to a lack of domain knowledge during the requirements and design phases, confirming that DDD fosters understanding between businesses and developers.

According to Forrester, development teams practicing an iterative DDD model work 60% faster than if they spent months on upfront analysis.

Research conducted by the University of Cambridge found that modeling domain knowledge within a DDD framework leads to a 29% increase in team productivity. Clearly, this approach unlocks internal domain knowledge.

So why do companies need this approach, who uses it, and what is its essence?

Core Principles of Domain-Driven Design

Domain-centric design is based on several key concepts that enable the creation of domain-centric software.

• First is the prioritization of the domain model. It represents the underlying business entities, behaviors, relationships, and rules. Code implementation directly reflects the domain model, not the other way around. The model is developed iteratively, not predetermined in advance.
• Another core principle is the development of a ubiquitous language. This shared vocabulary of developers and business experts standardizes terminology and domain knowledge, eliminating ambiguity and inconsistency across teams.
• DDD also includes strategic and tactical design phases. Strategic design focuses on the high-level organization of the domain as bounded contexts and sub-areas. Tactical design encompasses patterns and lower-level implementation components such as entities, services, and repositories.

Additional concepts include emphasizing exploratory modeling rather than analysis, continuous domain immersion, and using ubiquitous language for documentation.

By combining modeling, language, and context-based techniques, DDD enables the creation of systems that focus not only on technical requirements but also on the core concepts of the domain.

In this context, Hexagonal Architecture and Clean Architecture immediately come to mind, which share the common goal of task separation. You can isolate core business logic from external problems by dividing applications into loosely coupled components.

Let’s look at the elements that define strategic and tactical design and how they affect the result.

Strategic Design

In the context of DDD, strategic design is an essential part of software development. It includes the following main aspects:

• Overview: Strategic design begins with an overview of the problem domain and business value. In this step, key concepts and processes are explored, and key business needs and goals are identified.
• Problem space and solution space: The strategic design framework identifies two main conceptual spaces: the problem space and the solution space. The problem space focuses on exploring and analyzing the business domain, identifying entities, aggregates, services, and the relationships between them. The solution space is concerned with creating a model that effectively solves the problems identified in the problem space.
• Restricted contexts: Restricted contexts are limited subdivisions of a domain that correspond to the areas of responsibility of specific development teams. Each context defines its entities, aggregates, services, and rules. Managing context boundaries is essential to isolate and understand the different parts of the domain.
• Core domain: The core domain is the core of the business, its most important and valuable part. Within strategic design, the core domain is critical because it is the focus of development and contains the fundamental abstractions and business rules that define the software’s functionality.

Strategic design in the context of DDD enables the creation of effective strategies for software development by considering the characteristics of the business domain. This helps developers create software that meets business requirements, scales flexibly, and is easily maintained over time.

Tactical Design

Tactical design is part of the software development methodology. It is responsible for a defined set of tools and approaches to create efficient and flexible architectures that reflect the business domain and ensure data integrity.

1. It starts with an overview of the business domain and its requirements. This step analyzes the core processes, entities, aggregates, and the relationships between them. The goal is to gain a deeper understanding of the core components of the domain.
2. Next, we focus on the heart of the application, also known as the core aggregate. The core aggregate is the primary interaction element and contains the domain’s key logic and data integrity. It defines the core operations and business rules.
3. Moving on to the tactical design toolkit, which gives us a set of rules and patterns for building an effective application architecture. It includes concepts such as Value Objects, Entities, Services, and Aggregates. This toolkit helps developers to create an agile architecture.
4. One example of using the tactical design toolkit is the creation of repositories. Repositories are responsible for storing and retrieving data from the repository of a specific entity or aggregate. They provide a single interface for interacting with the data repository and encapsulate data storage details.

Tactical design also distinguishes between application services and domain services. The application services coordinate actions and interactions between different entities and aggregates within the application. As for domain services, they store business logic and execution of operations related only to the domain model.

To summarize, tactical design helps to create effective architectures that reflect the business domain and guarantee data integrity. Using tactical design tools simplifies application development and support, making it easier to understand and scale complex domains.

Bounded Context and Ubiquitous Language: Their Role in DDD

The bounded context within DDD is a localized set of models and rules applied within a specific business domain. It helps to delineate and restrict different aspects of the system within a particular context.

A bounded context represents the boundary within which development takes place and ensures consistency of models and rules within that context. Accordingly, it can have its own modeling language and even business domain-specific terms.

It allows developers to better understand and model a complex subject area and facilitate stakeholder communication. Limited contexts can exist in parallel and interact through defined interfaces.

Another equally important concept to focus on when we talk about DDD is ubiquitous language.

It can be characterized as a common language used and understood by all development team members.

A ubiquitous language is created and maintained within a limited context. It includes specialized terms, phrases, and rules that reflect the system’s business understanding and subject matter. This language serves as a familiar base that facilitates effective communication between different team members.

Its primary mission is to help avoid misunderstandings related to different interpretations and understandings of terms or concepts and, in a sense, contribute to a deeper and more accurate modeling of the subject area.

The Key That Unlocks New Solutions: What Does the DDD Approach Bring to the Table, and Who Does It Work For?

If a project deals with intricate business logic, ever-changing processes, relationships, and business rules, it becomes an ideal candidate for implementing Domain-Driven Design principles. By applying DDD, developers can effectively navigate complex domains and create software solutions that accurately reflect the intricacies of the real world.

DDD is also highly adaptable and flexible to future changes. As businesses evolve and face new challenges, software solutions must keep pace. The clear separation of limited contexts and the use of a ubiquitous language facilitate the seamless integration of updates and modifications, minimizing the need for major system-wide changes. The result is smooth transitions, reduced stress levels, and cost savings for the company.

The Power of Small DDD Teams

Domain-driven design lends itself well to small, autonomous teams. The “two-pizza team” concept exemplifies this. The idea is that a team should be small enough to be fed by just two pizzas. This enables focus, alignment, and productivity.

We see the “two-pizza team” approach intertwined with DDD being successfully applied to industry leaders like Netflix (this allowed them to scale the platform quickly) and Uber (they were able to flexibly isolate incidents and manage fluctuations in demand).

It seems like DDD is an exclusive club with members like Netflix, Uber, and our humble WebLab Technology. We’re in good company, aren’t we?

Yes, we use DDD as one of our primary approaches to developing complex business software. And it seems we are among the few companies working with it.

Someone created a discussion on the DEV Community portal asking, “How do we find companies that follow a domain-driven design approach?”

To find DDD practitioners, follow the trail of well-structured conversations… or just look for our team!

But someone decided to suggest that you can find such companies if they mention in their proposals that they work with DDD. The demand is there, but there are not so many offers.

As you can see, small, cohesive teams play a crucial role in complex domains. They can quickly accumulate knowledge and use the language of their field universally.

For companies adopting DDD, embracing the two-pizza team paradigm unlocks productivity and innovation across domains. The nexus of small teams and domain-driven design is powerful.

In particular, DDD enables:

• Improved communication: The ubiquitous language allows developers and business experts to collaborate more efficiently.
• Business alignment: The software design directly reflects real business processes and goals.
• Flexibility: The modular architecture makes it easy to modify applications as needs change.
• User focus: Focusing on the domain allows the creation of solutions tailored to user needs.
• Efficiency: Close involvement of subject-matter experts results in products that solve real business problems.

DDD and Small Organizations: Possible Challenges

In smaller organizations, DDD integration may not be as prevalent as in larger companies. However, the ability to integrate depends on specific needs and priorities. DDD integration can be beneficial if a small organization has a complex subject area or faces the need to effectively manage and model business processes.

However, be prepared for the obstacles that may arise, which include:

• Limited resources: Smaller organizations may have limited developers and time, making it challenging to implement a new methodology.
• Difficulties in subject matter modeling: DDD integration requires a deep understanding of the subject area and modeling it correctly. Lack of software development experience can be a barrier.
• Resistance to change: Smaller organizations may be more prone to resistance to change, especially if existing processes and software architecture are already established.
• Technical limitations: Outdated technical infrastructure that does not support full DDD integration.

Indeed, not all of these hurdles are true for all small organizations. Every organization has unique characteristics and challenges that can impact DDD integration.

DDD Implementation: Start Gradually

Now, let’s look at the basic steps of effectively implementing DDD without getting confused by the complexities.

1. Start Small

Starting small with DDD is advisable, especially when new to it or dealing with a large system. Pick up a small, less critical part of the application and start applying DDD.

2. Continuous Learning

Often, the first implementation might not be perfect. It’s a continuous learning process. Don’t get disheartened by initial challenges. Understand the mistakes and learn from them.

3. Collaboration

DDD isn’t just about coders. It involves the entire team: developers, project managers, system analysts, domain experts, etc. It demands a close collaboration for knowledge sharing and software development based on business demands.

Finally, as we’ve said before, one must remember that DDD isn’t always the solution for all projects. The complexity it introduces might not be necessary for simple applications, making it essential to evaluate its need in the project.

Intersection: The DDD Connection to Agile

So, how does the intersection of DDD with Agile manifest itself? DDD and Agile share similar principles, setting the stage for their successful integration.

1. Active engagement with stakeholders: In DDD, this is reflected in the pervasive use of language that facilitates effective communication, while Agile focuses on collaboration to create value.
2. Flexibility and adaptability: Both methodologies are adaptable. Agile is designed to accept and implement change, while DDD models evolve to reflect domain understanding.
3. Iterative development: Agile is focused on developing software in small, incremental steps. In DDD, models are refined as they evolve, which brings us back to the iterative nature of DDD of Agile.

The connection between DDD and Agile manifests itself as a complementary relationship. Thus, using DDD in an Agile environment can streamline communication, ensure better alignment with business requirements, and deliver high-quality software.

We can confidently say that industries that rely heavily on domain knowledge find particular value in DDD’s focus on learning the intricacies of their specific domains. Ultimately, the essence of domain-centered design lies in its ability to create high-quality software that is closely aligned with the needs of businesses and their customers.

For WebLab Technology, the DDD approach is an integral part of our ideology of building long-term technical partnerships with customers. And it aligns with Conway’s Law, which states that software systems reflect the communication structures of the organizations that build them.

Our specialized teams create architectures that are a natural fit with our customers’ domains, and the deep involvement of domain experts allows us to create a smooth communication chain that involves everyone. Perhaps the more companies realize the need for this approach, the more valuable DDD benefits will be discovered in the future.

After all, as Eric Evans wrote in his book, “to communicate effectively, the code must be based on the same language used to write the requirements — the same language that the developers speak with each other and with domain experts.”