To DDD or not?

You might have heard about this thing called DDD which stands for Domain-Driven Design. The name does not reveal much about itself. So maybe you wonder why should you listen about it. What’s so good in it? What problems does it try to solve?

If you look at the cover of the Blue Book, you will see the answer.

The subtitle says “Tackling Complexity in the Heart of Software”.

That’s what DDD is all about!

Managing, fighting and struggling with complexity. Building software according to certain principles which help us build maintainable code.

So… If every 2 months you start a new simple application, a new prototype which may or may not be successful then probably DDD is not for you. Or not?

There are hundreds of articles out there stating that you should only apply DDD on years-long projects which are supposed to have even more years-long time of usage. When the cost of maintenance and expanding is much more important than the cost of development.

After quite some time practicing Domain Driven Design, I can say for sure that I have enough arguments go against that belief and I know that most of you will eventually agree with me.

Domain Driven Design is just a name for a set of techniques such as: Bounded Contexts, Domain Events, Aggregates, Domain Models & Entities, Repositories, Value Objects, Read models, Application Services, Commands etc. As with every programming technique, you don’t need to use all of them. You can only pick those that you benefit most from and start using them at the beginning. In my projects, the most beneficial were Bounded Contexts, Domain Models & Entities, Value Objects and Repositories.

Are you suggesting to separate Domain and Persistence for a 2-month application?

The separation of Domain and Persistence via Repositories is something that is maybe too complex for most applications. Ok, for small scale application it is time consuming, it is however necessary, possible and relatively easy to implement. But it's not only that!

There are principles of DDD that come in handy, even in applications you only spend two months on. The most important of which, is the idea of ensuring that the language you use to describe the system and interactions in english should mirror the code. There are a lot of lessons here. It's about DX, empathy, readability. The concept that "don't make the developer have to think.." is implicit in this guideline.

This means not only that you ensure that high-level, developer-only API's match natural language as closely as possible, but also that the naming is consistent everywhere. This ensures that the same natural language tokens are used through every layer of a system. In addition to this, the concept that you should be able to tell a story about how a system is used and works, and turn that into code is truly valueble.

However, the key for a successful DDD application is not lying in its architecture or coding. It lies on the good preparation which must be done way before kick off. You should identify the needs with Event Storming, set up a common Ubiquitous company language and think in advance before you start typing!

Which of the DDD principles should I use for my application?

Well, a friend of mine would have said: it depends! It depends on the needs and the technologies you are using.

In my opinion there are always useful DDD techniques that are applicable for any application no matter its scale or size!