According to Paradigma Digital, Domain Driven Design (DDD) is a holistic approach to software design that places the Domain at the center, that is to say, the domain or business problem. It is not a methodology to develop software. The DDD provides framework practices and terminologies for making design decisions which focus and accelerate the management of complex domains in software projects.

It was proposed for the first time by Eric Evans. He is a software design thought leader and author of the book “Domain-Driven Design” (Addison-Wesley 2004). In this book he explains how the DDD represents different keys, terminology and patterns used to develop software where domain is the central part of an specific organization.

Thanks to DDD we are able to know in a comprehensive way the business problem and what customers want to develop. This way it is possible for us to divide it into subdomains in order to achieve modular solutions, which reward the adaptability of each subdomain and, therefore, the adaptability of the solution in general.

At Tecnova we will look through the main concepts of DDD, its advantages and disadvantages and where it can be used.

What will DDD do?

According to Just Digital, using DDD will depend on the specific case or project since we may come across with the complexity of many applications not being in the technical part but in the logic of the business domain.

“The dilemma begins when we try to solve domain problems with technology. This means that, although the application works, there is no one actually capable of understanding how it does it” they assert. Therefore, one of the purposes of using DDD is to have a design closer to natural language than to technical language.

As defined by Paradigma Digital, for this to make sense “it must be complemented with the appropriate decision on design patterns, dependency inversion (having special care with cyclical references), encapsulation and ACL’s (anti-corruption layers, a design pattern referred to by Martin Fowler, and that deal with the integration between domains.)”

Main concepts associated with DDD 

In DDD, it is crucial to pay attention to the following terms. Let’s check:

Domain logic

Domain logic is the purpose of modeling. It is commonly known as business logic. This is where business rules define how data is created, stored and modified.

Domain model

The domain model includes the ideas, knowledge, data, metrics, and goals that revolve around the domain (the business problem) to be solved. It contains all the rules and patterns to help you deal with complex business logic.

Subdomain

A domain has multiple subdomains involving different parts of the business solution. For example, an online retail store might have a product catalog, inventory and delivery as its subdomains.

Design patterns

Design patterns focus on reusing code. No matter how complex the problem you encounter, someone who has been doing object-oriented programming has probably already created a pattern to help you solve it. Dividing your problem into its initial elements will lead you to your solution.

Bounded context

Bounded context is a central pattern in domain-driven design. Is in the context where the code is implemented, after having defined the domains and subdomains. Bounded contexts represent boundaries within which a particular subdomain is defined and enforced. Here, the specific subdomain makes sense, while others don’t. An entity can have different names in different contexts.

The ubiquitous language

Ubiquitous language is a methodology that refers to the same language that experts and developers use when talking about the domain in which they work. This is necessary because projects can face serious problems with interrupted language. Meaning, between the software developers and the client requesting the development.

That is why it is essential to define a set of terms that both parts use. All terms in the ubiquitous language are structured around the domain model.

Benefits of using DDD

• Effective communication between domain experts and technical experts through Ubiquitous Language.
• Focus on the development of a divided area of the domain (subdomain) through Bounded Context.
• The software is closer to the domain, and therefore closer to the customer.
• Well organized code, allowing testing of the different parts of the domain in isolation.
• Business logic resides in one place and it is divided by contexts.
• Long-term maintainability.