Green Files

What really is DDD and when does it apply?

Day: 06/01/2022 - Time: 09:36:51

Domain-Driven Design is an object-oriented software modeling pattern that seeks to reinforce concepts and best practices related to OO.

This comes in contrast to the common use of Data-Driven Design or Data-Driven Design, which most developers use without even being aware of it.

Data-Driven Development

I've heard several times that data is the most important thing in a company, so modeling should always start with the database in mind.

It is not uncommon for .Net, Java and C++ developers to start a system by establishing the types they will use and the relationship between them. These types are usually "dumb" objects, with getters and setters, representing nothing more, nothing less, than a database table.

The problem with this approach is that it doesn't make good use of Object Orientation features. Many think that getters and setters are the pinnacle of encapsulation, but in practice these methods allow the user to retrieve and change all attributes. There is no gain, other than a lot of unnecessary code.

Anyway, a lot of people think they are using OO, but the classes could be easily replaced by registers or structures, according to the language used.

Domain-Driven Development

The initial idea of ​​DDD is to go back to pure OO modeling, so to speak. We should forget about how data is persisted and worry about how to better represent business needs in classes and behaviors (methods).

This means that in DDD a Customer may not have a setter for its common attributes, but may have methods with business logic that in this business domain belong to the customer, such as void associateNewCard(Card) or Account retrieveAccountInformation().

In summary, the modeled classes and their methods should represent the company's business, even using the same nomenclature. Data persistence is put in the background, being just a complementary layer.

When not to use DDD

Sometimes only one CRUD is needed

DDD is not a one-size-fits-all solution. Most systems have a good part composed of basic registers (CRUD) and it would not be appropriate to use DDD for this. The DDD should help in the modeling of the most important and most central classes of the system in order to reduce the complexity and help in their maintenance, after all this is the objective of the object-oriented principles.

Sharing data with other systems

Integration routines that receive or make data available to other systems should not be "smart".

Many developers end up modeling their business classes trying to solve the system's internal issues and, at the same time, thinking about how these classes will be exposed to other systems.

Standards like DTO (Data Transfer Object) that use "dumb" objects are better suited for this.

Final considerations

DDD does not try to solve all problems at all layers of a system.

Its focus is on modeling the main business entities using the appropriate language of that domain to facilitate maintenance, extension and understanding.

Particularly, I would not follow the pattern to the letter, because there are numerous patterns and variations of OO modeling. Study the principles behind these patterns, as they are often similar, and see what works best for each project.