The Rise of DDD: Why It's Becoming a Must-Know Topic for Developers

It is maybe that I give more attention to it, or that it is simply becoming a trendy term to use, but I am reading more and more about Domain Driven Design (DDD).

Why do we use domain driven design ? #

This concept is popular in the recent software engineering design discussions, even though it was first introduced in 2003 in the book “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans. It is usually presented as an approach to create more maintainable, scalable and robust software systems.

This might still be too vague for you, as it was for me. So, let’s try to dive a bit deeper:

At its core, DDD introduces us to the idea that our application’s structure should be shaped by the business domain. It means that, instead of designing our application by considering it an exclusively technical exercise, before anything else, we should work with the domain experts to understand deeply the problems we are trying to solve, and then model the software accordingly.

The resulting software should be more aligned with the business’s needs and provide a better solution overall.

Ubiquitous Language #

How do we apply this practically ? For example, with ubiquitous language. That is, a shared language between the developers and the domain experts. This should bridge the technical jargon of software development, and the more common language of the business domain. By clearing communication between all parties, we prevent misunderstandings and miscommunications, which sometimes can lead to software that are technically great, but doesn’t meet precisely the business requirements.

That can seem obvious, or even strange that such concept plays a huge role in a software development approach. But let’s not forget the fact it tries to conciliate the engineering and the business.

Bounded contexts #

Another important concept, in DDD, is the use of bounded contexts. Which is basically dividing a large application in to smaller and more manageable parts, which corresponds to a specific aspect of the business domain.

For instance, if we are talking about a clothing retail website, we might want to divide our bounded contexts according to the following subdomains:

• Order subdomain: managing the orders, customers, shipping, etc…

• Inventory subdomain: managing the stocks, the availability, etc…

• Product subdomain: managing the product displays, the categories, the ads features, etc…

• Authentication / Identity: managing who has access to what, etc…

  …

These subdomains can be understood on their own and made evolve/maintained by autonomous teams.

They may be divided in three different categories:

• Core subdomains: the money maker, essential for the business (e.g: Product subdomain)
• Supporting subdomain: support the core subdomain (e.g: Inventory subdomain, order subdomain)
• Generic subdomain: solved problems (e.g: Authentication / Identity)

Approaching a new business domain with a DDD approach can start with a phase called “strategic design”, where we explore and identify all the various subdomains.

Patterns aligned with DDD #

Some patterns have common goals with DDD, which are to enhance the rationality, maintainability, and flexibility of our software. These include the use of:

• Entities: Object that has an ID, and is mutable (e.g: a product in our clothing retail website)
• Value objects: Object that has no ID, and is immutable (e.g: An Address of a customer)
• Aggregates: Collections of Entities and Value objects, that are treated as a single unit. (e.g: the listing of multiple products)

We can identify these implementations details during a phase called “tactical design)