DDD - what is it?

DDD is a shortcut for Domain-driven Design. I don’t fully agree with definition given by Wikipedia. To me DDD is more subjective and is more like Clean Code or Agile. We more or less know what it is, but it is very different how given teams implement this.

I must admit, that I struggled with understanding of DDD for quite a long time. It was not easy even after reading Domain-driven design by Eric Evans. There is another book that I highly recommend reading: Implementing Domain-driven design by Vaughn Vernon. Problem I had after reading those books was that I was so focused on code that I did not catch what is the key.

DDD to me is a set of principles that software should be build with. The main goal for any software is to solve real problems, be response for given need. For example, Todo list app - helps people to organise stuff and keep not forgetting about things.

What practises DDD comes with?

I will try to iterate few, I think are most important.

• understand it - understanding of business domain, make sure you understand the business domain, do some exercises like event storming
• name it - ubiquitous language, software and business should speak the same language, no exceptions, translations, mappings
• identify context - be aware of context, some domains are quite huge, we need to be aware what context we are in
• craft it - write clean code oriented on the domain, make sure your code is clean and oriented around the business domain, avoid anemia, build good API - regardless of the architecture (monolithic, microservices, …)
• revise it - revise your business and make sure you understand only constant thing in the world CHANGE, adapt to it

Why I do prefer to work with DDD?

Because it brings a value. Where is the value?

If we stay close to business language it is much easier to capture real behaviour, change it, adapt and not create artificial functionalities.

Moreover, the time I work within the team. It means, I am not the only one working with the code. This being said the only way I am able to understand this is to keep it connected to the business as much as possible. It protects the team to work efficiently and progress with functionalities without hacking. If there is a time when we think of introducing a hack or same code smell it is a right time to rethink the domain and do step back.

What we can do?

Don’t worry, stay calm, practise, focus on business, ask questions, repeat.