Building a Domain Driven Design Framework

Domain Driven Design came back with full force among many companies.

What impresses me is that we still don't have a good base framework to define what is a value object, an entity, or a "validable" behaviour.

If we think deeply, it makes sense not to follow a framework because we need to protect our core business unities.

I defend that a company should maintain its definition of what is every element of Domain Driven Design because the implementation can be very philosophical, which can bring different interpretations.

But I still believe that some techniques can be shared and bring value and productivity to companies implementing Domain Driven Design.

My objective here is to bring light to this matter, give good insights about how to build an effective Domain Driven Design framework with hands-on code and turn on some public discussion among developers with the same mindset.

If the dev community buys the idea and helps push this framework forward, I'll maintain it.

The Build Blocks and the Base Concepts

Let's think about our big picture first, without going into details.

Once we have the core concepts clear, we can move into implementation details.

Validatable

If we start to think about elements of Domain Driven Design, almost everything is about validation and making sure you can trust your data.

It would make sense to standardize the validation behaviour, creating an abstract class called "Validatable".

This base class will enforce us to implement a validation process on every implementation.

Then we can extend this class to start defining what is a Value Object and an Entity. Both should be abstract classes as well.

Working with purist DDD definitions, we can never allow a Value Object of Entity to be created without throwing an exception.

But I want to be flexible because lots of implementations can have the Entities invalid until fields are filled and a validate method is called.

Any developer should easily apply any kind of behaviour. For me, makes much more sense to use the Notification Pattern.

But I also like the idea to enforce validation by default, let's talk about it soon.

Value Object

The Entity class is the protagonist here. Entity inherits the Validatable behaviour that should be easy to extend.

For full flexibility, we need to have three strict defined interfaces: Properties: Can contain other entities and Value Objects. Plain Object: the data to be extracted from the Entity, necessary to store data into databases and for any other purposes Input: What we accept while creating an instance of an Entity.

But it's not cool to write loads of code to just define an Entity. write a class and also plus 3 interfaces is too much, that's why we need to create a standard behaviour, defining only the Entity and maybe one interface, and use our type system to infer automatically the other interfaces.

We should focus on the properties, with the data to be validated, and let the framework do further magic.

An entity should also recursively validate others children's validatable stored inside properties and join the validation messages to comply with the notification pattern.

Another desired behaviour we want is to make the entity recursively extract plain values from child Value Objects and Entities, we don't want to keep repeating obvious codes.

So, our Entity should validate and fetch data from itself and its Validatable Children.

Entity

The Entity class is the protagonist here. Entity inherits the Validatable behaviour that should be easy to extend.

For full flexibility, we need to have three strict defined interfaces:

• Properties: Can contain other entities and Value Objects.
• Plain Object: the data to be extracted from the Entity, necessary to store data into databases and for any other purposes
• Input: What we accept while creating an instance of an Entity.

But it's not cool to write loads of code to just define an Entity. write a class and also plus 3 interfaces is too much, that's why we need to create a standard behaviour, defining only the Entity and maybe one interface, and use our type system to infer automatically the other interfaces.

We should focus on the properties, with the data to be validated, and let the framework do further magic.

An entity should also recursively validate others children's validatable stored inside properties and join the validation messages to comply with the notification pattern.

Another desired behaviour we want is to make the entity recursively extract plain values from child Value Objects and Entities, we don't want to keep repeating obvious codes.

So, our Entity should validate and fetch data from itself and its Validatable Children.

Let's code

Now that we have the base definitions for our Domain Driven Design framework, it's time to start putting hands-on code.

In the next blog post, I'll start coding the Validatable behaviour and keep the progress in a GitHub repository.