Back to posts
Domain-driven design is a methodology to create software for complex business requests, described by Eric Evans in his book “Domain-driven design, Tackling complexity in the heart of software”.
When I talk to developers of companies claiming the “do” domain-driven design, they often start to talk about technical implementations. This is not what domain-driven design is about, but rather a welcome result of applying this methodology.
We must understand that there is a problem space and a solution space. In the problem space is the real-world problem we want to solve. This is where the developers must work together with the domain experts and model the problem together. It’s always a good idea to visualize the problem to initiate a discussion about the problem between domain experts and with the developers.
Next, after the model is made, we can assume that developers have a deep understanding of the domain, and they can develop a solution.
Domain-driven design introduces the concept of a ubiquitous language. This is a language that is clear to anyone involved and has a certain meaning within some boundaries. Across boundaries, a “word” can have different meanings. Those boundaries are also present within the same company. When you succeed in defining the ubiquitous language in a proper way, bounded contexts will also emerge. The big problem you want to solve is chopped into smaller problems. Each small problem is easier to understand and to solve.
Resulting from those bounded contexts, you can develop services for a service-oriented architecture or a microservice architecture. Your service will have to cooperate with other services and your team will have to deal with teams behind those services. There are some team and services patterns described in domain-driven design like the upstream-downstream pattern, how to recognize them and how to act upon it.
The result of all this work must also be translated into good working software. And there are some tools in our toolbox to nicely translate this into readable and maintainable code. These are value objects, entities, aggregate patterns, repositories, domain events, services, and factories. These tools go nicely along whit clean architecture, event-driven architecture, CQRS, and event sourcing.
To get started with domain-driven design, I highly recommend “EventStorming” by Alberto Brandolini. EventStorming is a flexible workshop format for collaborative exploration of complex business domains. In this workshop participants, domain experts, and developers will start to add domain events, which are events that matter for a business, on a stickie on a timeline. Those stickies will be a start for discussions on how to properly name things. This naming will be your ubiquitous language. Stickies will be ordered chronically and grouped together, which will show you the bounded contexts you will work with.
Of course, there are different levels on how much you can use and implement the domain-driven design in your company. But it’s always a good idea to look at a problem from different angles. Using proper naming and making it less cumbersome to read code is always a good investment and will make your core business code future-proof.
You want to go deeper into the subject? Have a look at our webinar about domain-driven design with Jurgen Stillaert.
Jurgen is a passionate technical lead who aims to make complex structures understandable for his team mixed with a little bit of fun. Make sure to contact him if you have any questions regarding domain-driven design!
