The value of using Domain Driven Design

From time to time I come across the relevant question of the value of using Domain Driven Design. Are there any hard numbers to use in convincing management about the benefits of DDD?

Hard numbers are really hard to get in software development since you never ever develop the same system twice and even if you did, it wouldn't be the same since you would have learnt a lot from the first attempt. But I'll share some thoughts and observations on using DDD.

By emphasizing communication with domain experts in developing the ubiquitous language DDD helps get you started on the right foot. Any system is simple from the beginning. The first set of functionality is never complex to implement since you have no other code to conform to and you tend to start with something basic. It means it is easy to just hack something together mixing levels of abstraction and business logic with technical complexity. Since first requirements are simple, the first complexity tends to come from unfamiliar tools like ORMs or other technical frameworks. Since we all are technicians at heart these things often become most important and the architecture tends to be more about technical concerns than the domain. All of which, we know, lead to a mess when requirements get more complicated.

By using DDD we are turning the focus away from technical concerns and instead focusing our effort on the business domain. With a bit of domain modelling, including test driven implementations, we get to investigate a larger set of requirements before going into technical details of persistence and other layers. A lean principle is to delay hard to change decisions to the last responsible moment, e.g. not deciding on a hard to change persistence model until we know what the domain really looks like. All in all, this leads to better architecture because the architecture is centered around the domain, not around technical frameworks.

Another aspect is complexity. What you consider complex depends on what you already know. I once worked with a large system where some parts were implemented using DDD and other parts were, what I would call, "undisciplined" transaction scripts. I think TS have their proper place and use, but implementing them in a way mixing business logic with technical concerns is never right. Hence "undisciplined". In this project I heard people complain about different things they thought was complex. Those people being unfamiliar with DDD but having a long history of working on the system thought the TS code with mixed concerns and very few abstractions was fine since they saw exactly what was going on and they "knew" what the context was and how everything worked on a detailed level. And they thought the DDD approach of separating things into different layers and building abstractions for business concepts just added complexity.

Then we had the newcomers, that didn't have any prior DDD-experience either, that struggled with understanding the domain. Even though DDD was new to them they pretty quickly picked up on the concepts and thought it was a great help in understanding the domain. To them it was the TS code that was most complex since it didn't make any difference between lines of business logic and those of database interaction.

These are two aspects on "the value of DDD". In another post I wrote about DDD being so much more than a set of technical building blocks and I think the most value from DDD is gained when wisely deciding on what parts to apply in each unique situation.