If we were to ask in any technical community what DDD is, many would be able to define, perhaps, in a single sentence: “DDD is an approach to building software with a focus on the domain.”
In fact, this statement is true!
But we can say that DDD is an approach for you to build your domain model in the right way.
But what is domain model?
If we look for the definition of the word “model”, we will see that it is a “representation, on a reduced scale”, and once we understand which domain is “scope” we are working, we conclude that a domain model is the representation of the problem in the real world.
This reminds us a bit of the academic definitions of when we are learning Object Orientation: “A class is a representation that describes behaviors and attributes of entities in the real world.”
But that does not mean that other programming paradigms cannot be applied to enjoy all the benefits of DDD.
DDD is not architecture
Initially the DDD is adopted as a set of patterns and good practices of software development.
If you associate that a project uses DDD because of Entities, Services, Repositories, etc. And in rare situations it also uses Value Objects, Aggregates, Events, Modules and Factories.
I have bad news: you are mistaken!
To this type of approach we give the name of DDD-Lite.
In a simplified way DDD-Lite leads to the construction of poor domain models, and the goal when using DDD is to build rich domain models.
Tips
Based on my experiences and the literatures I have read, such as “Eric Evans, Domain-Driven Design – Tackling Complexity in the Heart of Software”, “Vaughn Vernon, Implementing Domain-Driven Design” and “Vaughn Vernon, Domain-Driven Design Distilled”, I suggest separating DDD into four parts as a learning approach:
Concepts: Model, Domain experts and other terms that do not qualify as strategic design, tactical design and architecture I classify as concepts.
Strategic Design: Also called strategic modeling, it is a pillar of the DDD whose main goal is to define Bounded contexts, Ubiquitous Language and Context Maps along with the entire project team.
Tactical design: Also called tactical modeling, it is a pillar of DDD related to “Building Blocks“, which are Entities, Services, Repositories, Value Objects, Aggregates, Events, Modules, Factories, etc.
Architecture design: refers to the style of architecture you will use. You can use different styles of architecture (Hexagonal, Layered Architecture, CQRS, etc.) to apply DDD.
You need to fully understand each of these issues, so that you can actually succeed in implementing DDD.
Conclusion
When we build software, we build with the intention of solving or improving some aspect of business, so there is no sense in having software that is not able to solve what is expected of it.
The DDD assists us so that our efforts are not wasted.
Implementing DDD is not trivial and should be analyzed if it really makes sense. The DDD exists to be applied in complex business scenarios. If your domain is not as complex, DDD may not be the best choice.
