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 tho it was first introduced in 2004 in the book “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans. It is usually presented as a way 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. In simpler terms, it means that, instead of designing our application by considering it an exclusively technical exercise, we should work with the domain experts to understand deeply the problems we are trying to solve and 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.

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 processing: managing the orders, customers, shipping, etc…
• Inventory Management: managing the stocks, the availability, etc…
• Product management: managing the product displays, the categories, the ads features, etc…

Patterns aligned with DDD #

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

• Entities: Objects that have a distinct identity, a lifecycle, and are defined by their attributes and behaviors
• Value objects: Objects that are immutable, a unique identity and are defined solely by their attributes.
• Aggregates: Collections of Entities and Value objects, that are treated as a single unit.
• Repositories: Abstractions for storing and retrieving Aggregates from data storage.
• Domain events: Discrete events, that represents at a given moment something happening within the domain.