A Beginner’s Guide to Domain-Driven Design Boiled Down to One Image
Domain-Driven Design (DDD) is a tough beast to understand, but the core concepts behind it I think are remarkably simple and will make you write better code, and this image symbolizes its core concept to me.
That core concept is the following: Can you solve your problem in your domain space?
DDD makes a clear distinction between things that are on the outside of your domain (real nitty gritty things like the files and database icons pointing inwards) and things that are inside of your domain space (core).
This domain space we call the core is in essence an abstract world. This is a clean and pristine world. This core should not have to worry about real world details such as file formats and databases and persistence. This core should be an abstract world filled with abstract concepts in which you can solve your problem.
The question then becomes: Can you solve your problem in this world free of the details and restrictions of the “real” world?
If yes, then the rest of the process becomes straightforward:
- Translate external real-world elements into domain objects
- Solve the problem using these domain objects in the core
- Translate back these domain objects into real-world nitty gritty items.
That’s it. That is the core of Domain-Driven Design: Can you solve your problem in your domain space (core)?
Comments