Introduction to Domain Driven Design (DDD)

Domain-Driven Design (DDD) is a software development philosophy first introduced by Eric Evans (“Domain-Driven Design: Tackling Complexity in the Heart of Software.”) that emphasizes the importance of understanding and modeling the business domain.

In order to do so, DDD advocates for the use of a well defined domain model that acts as a representation of the business domain and its entities and relationships. In DDD, it is expected to have a domain that can be understood by not only developers but domain experts too. Because of this, it also emphasizes the importance of sharing a consistent naming for all the domain elements across the development process. This includes not only the actual code but the documentation, the communication within the teams... etc.

Let's dive now into the technical aspects of DDD:

In order to encapsulate the different parts of the domain, contexts are used. These contexts are meant to define logical boundaries within the system and to have its own language, isolated from others and with its own entities and relationships.

This separation allows the developers to focus on each part without additional complexity from other areas that are not related with.

We have mentioned the entities a few times now but, what are they?

Entities are representations of objects in the domain that are not defined by their properties, but their identity (This means that if we took this post as an entity and I changed some of the content the post would still be the same, it is just that it has had a change)

Entities are intended to contain the business logic.

Other relevant concept in DDD is Value Objects.

Value objects are objects that don't have an identity, are immutable and are used for describing a concept from our domain. This could be a date, a name, an address...

They're very useful for setting rules in our domain entities:

Let's say we have an entity User that has an attribute called 'name' which is a string. If we used the "traditional" object approach, we would just define the class, the attribute as a string and a setter for it.

Since our user must have a name, an empty string would be an invalid value for our name field, so we could set validation in the setter to ensure no empty strings are provided:

Now this could be enough for small entities, but as soon as we escalate and the entity grows our code will be harder to maintain, so we will use Value Objects instead.

Following the same example we would create the value object for our name:

Now, in our entity, we only need to set this value object as the property:

So the validation is done already and we don't have to pollute our User entity with validations that are not User-specific.

Also note that since the value object is immutable if we want to update the value we will need to create other instance with the new value instead.

In the next article we will talk about Aggregates, Domain events and how DDD derivates into other very useful approaches in software development.

If this information is useful to you feel free to hit the follow button so you don't miss anything out!