Domain Driven Design explained WITHOUT complications

Today we are talking about a very popular topic in enterprise environments: DDD, or Domain Driven Design. It is often presented as something super complex because it is usually explained mixed in with patterns like Event Sourcing, CQRS or processes like Event Storming. Even though they can go together, they are different practices that can, and should (if the person explaining actually knows what they are talking about), be explained independently if what you really want is to understand the foundation of domain-driven design.

1 - What is Domain Driven Design?

Domain Driven Design (DDD) is nothing more than building a domain model to understand how the business domain works. 

And when we say business domain, we mean the business rules and the context around those rules. 

Imagine we are building software for a logistics company. The \"Domain\" is not the code, but the physical act of moving packages from point A to point B.

Using Domain Driven Design does not only affect the code, as it might seem, but aims for the software to be an exact reflection of these physical and legal realities, not just a database with an interface on top. To do that, there are several parts that are key and that we must apply correctly. 

1.1 - A shared vocabulary in Domain Driven Design

It is crucial that everyone involved in the project uses the same vocabulary. 

The whole team has to agree, usually guided by domain experts, to define that vocabulary.

This might look very simple at first glance, but it is not, because engineers, business people, or middle management can refer to the same action in different ways. 

For example, in our shipping company, we want to install a device to track vehicle location. What do we call that device? Tag (like an AirTag), beacon (because it emits signals), tracker (because it tracks the location), locator, or even telemetry unit if it sends more information than just GPS coordinates.

Defining this vocabulary is KEY so you do not waste time halfway through the project and you avoid confusion, which is what we call the Ubiquitous Language.

1.2 - Entities in Domain Driven Design

To tie it to the previous example, an entity is an object that has a unique identity that persists over time, regardless of whether its attributes change.

In our shipping system, a truck is an entity. Even if we paint it a different color, change the tires, or assign it a new driver, it is still the same truck (identified by the license plate). What matters to us is not only its current state, but who it is throughout its life in the system.

1.3 - Context in Domain Driven Design

Context is another crucial part of DDD because what we do is split complex areas of the domain into smaller parts, called bounded contexts, where each one will have its own vocabulary, implementations, definitions, etc.

That means the same word can mean two different things in different contexts.

An order for the sales department does not have to mean the same thing as it does for the logistics department or the accounting department. 

1.4 - Value objects in Domain Driven Design

A Value Object defines aspects of the domain that do not have their own identity; what matters are their attributes. If you change an attribute, you have a new object.

In our example, the delivery address (Street, Postal Code, City) is a Value Object. If you change the postal code, it is no longer the same address but a different address.

1.5 - Aggregates in Domain Driven Design

An Aggregate is as simple as having a group of entities and value objects that are treated as a single unit when it comes to data consistency. Each aggregate has a \"Root\" that we technically call the Aggregate Root.

In the transport company we have shipments that contain the Shipment entity, a list of packages, and a Route.

When we change the shipment status to delivered, we do not do it package by package, we do it through the shipment, making sure all packages comply with the rules before marking it as completed. The aggregate guarantees that nothing inside it is in an invalid state.

1.6 - Domain events in Domain Driven Design

Finally we have domain events (or domain events). These events are situations or actions that happen in other parts of the domain that we need to react to. 

Careful: it is important to know how to distinguish that these are events inside our domain. If they happen in a different domain, for us they are simply external events or integrations. 

Their main use is to decouple parts of the system and to react to the actions or events that occur.

2 - Advantages of using Domain Driven Design

The clearest and most obvious advantage for anyone who has worked with DDD from the technical side is that developers come to understand the domain they work in. 

You might think this is normal, but in my professional career, half the people I have worked with barely know what the company even does. So how it does it does not matter to them at all, and that shows when building software because with DDD they keep the real world more in mind. 

When engineers care about the rules and how the domain works, everything is smoother in the long run, not only the relationship between developers and the rest of the company, but also when it comes to understanding the complexity of what the company does. 

A lot of developers are in a cave where they only care about their code and that is it, which, from the company point of view, is not good. 

As for DDD and the technical side, as a general rule the code is more readable because it uses the same vocabulary as the domain side, so it is easy to maintain, understand, and commonly extend if the domain grows. 

3 - Where not to use Domain Driven Design 

As a general rule, DDD shines in complex domains. If you are building a simple CRUD or a microservice that just transforms data, applying full DDD is overengineering. The cost of aligning vocabulary, defining bounded contexts, and modeling aggregates is only justified when business complexity requires it.

As a general rule, if the problem can be understood by reading the database schema, most likely you do not need DDD.

4 - Conclusion

Domain Driven Design, even though on my blog I have placed it under architecture, is not a technical architecture, but a design philosophy. The goal is for your software to truly understand the business, with the same consistencies as in the real world, leaving trendy libraries aside.