Benefits of adopting DDD in your company

Lately I’ve noticed that many companies are trying to run away from DDD, and is something that I’ve suffered in my own flesh in the past during the interview processes. In this world of software there’re as many detractors as promoters of DDD. People who often dislike it argue that it comes with a lot of burden due to its layered architecture as well as its learning curve which is bigger than adopting another approaches for designing software. On the other side, people who really like it, emphasize its benefits.

As with any other approach there is no silver bullet, there’re better approaches than others, so before settling one for your company you have to balance between the pros and cons than each of them provide.

Which are the benefits of DDD?

DDD provides you a lot of benefits to both, technical and business perspective, which is translated in saving time, thus money.

The more relevant ones for me are the following:

• Separation of concerns whereby maintainability, scalability and readiability of your code is multiplied. Hence, your architecture will be cleaner.
• Protects your core logic into the domain layer, it’s not spread out throughout the code so it’s so clear where to go when you need to do a new change. Likewise, assessing the implications of those changes is very easy.
• Induces you to embrace SOLID patterns and good practices. Once again, by doing this the maintianbility, scalability and readiability of your code is guaranteed.
• Unifies the domain language (aka obiquitous language) across the company ensuring that everyone is aligned when addressing new problems and requirements. Talking and understanding the same language saves so much time and increase the quality significantly. Read this twice because it’s more vital than you think.
• It helps you to separate clearly and effectively your domains, therefore creating new teams that own them is very simple.
• Newcomers are productive sooner than with other architectures since it has a standardized folder structure by layers (domain, application, infrastructure) no matter the language you’re using. As your core resides in the domain layer getting familiar with it is not a complicated task.

When to adopt DDD?

Another important consideration for DDD is when to adopt it, do it when:

• Your application is gaining complexity. At the early stages of a startup you need to reach your goals as soon as possible, so it doesn’t make sense to start with DDD from scratch in most cases. Moreover, the majority of the products at those phases undergo lot of changes regarding its goals.
• After initial stages you’re attracting funds and your application won’t stop growing. Not tackling the complexity at the right time implies experiencing the consequences in the future.
• You’re developing an application that has a known complexity in its hearth. For example, is not the same building a service that delivers a newsletter than creating a booking system.
• Everyone in the team has a good background with DDD, applying it is effortless.
• Your legacy code is starting causing problems and what started simple is now quite difficult. At this point breaking it down into different domains will save your life, time and money.

How to adopt DDD?

So far, you’ve done enough reaserch and you clearly know that you want to adopt DDD in your company, but now you’re struggling about how to do it.

• If you’re not doing DDD from the beginning of the project in that case start applying it to one of the pieces, familiarize with it and repeat the processes with each parth you think are worthy.
• The decision should be taken by all the stakeholders involving the project, it cannot be an initiative from tech people.
• Engineers have to focus first on domain behaviors rather than code.
• Product team and engineering team must work closely. The most context they have about each other the better.
• You have to create a common language that reflects your domain problems and that everyone in the company understand when discussing about them.
• If you’ve never applied it before then read, read, and read. There’s a tons of articles, books and examples about it.

As always, first evaluate your requirements and go ahead with the simplest solution. Maybe an API CRUD is more than enough for the problem you’re trying to solve. By the same token, if you’re very sure that what you’re crafting is complex or is likely to have much more complexity in the near future then DDD is your ally, is the most cost-effective approach.