Some days ago I came 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 you to get 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 unfamilliar tools like ORMs or other technical frameworks. Since we all are technicans at heart these things often become most important and the archutecture 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 focus our effort to 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. An agile 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. Currently, I'm working with a large system where some parts are implemented using DDD and other parts are, 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've heard people complain about different things they think is complex. Those people being unfamilliar with DDD but having a long history of working on the system thinks the TS code with mixed concerns and very few abstractions is fine since they see exactly what is going on and they "know" what the context is and how everything works on a detailed level. And they think the DDD approach of separating things into different layers and building abstractions for business concepts just adds complexity.
Then we have the newcomers, that don't have any prior DDD-experience either, that struggle with understanding of the domain. Even though DDD is new to them they pretty quickly pick up on the concepts and think it is a great help in understanding the domain. To them it is the TS code that is most complex since it doesn't make any difference between lines of business logic and those of database interaction.
These are two aspects on "the value of DDD". In my previous 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 desiding on what parts to apply in each unique situation.