Domain Driven Design

What is Domain-Driven Design?

It is our job, as software engineers, to effectively transfer real-world business problems and solutions into the digital world. This is not an easy task. You have to understand how the business operates and what are its key advantages over the competitors. Exploring models in collaboration with domain experts and software experts is essential. To be successful you need to uncover and concentrate on how the business generates profit. We call this area the Core Domain.

There are different supporting pieces as part of the overall puzzle which enhance the Core Domain. We call those Supporting Domains. You need to pay special attention to the details because sometimes a so-called "very important part of the business" could be something generic and commonly used in other applications - a.k.a Generic Domain. For such cases, it is recommended to use an off-the-shelf product or leverage an open-source project and concentrate on the Core and Supporting domains. Otherwise, the software engineers will build something which does not bring value nor a competitive advantage to the client.

{% hint style="info" %} With Domain-Driven Design the focus is on the core complexity of the domain! {% endhint %}

{% hint style="info" %} Write software that models business processes explicitly! {% endhint %}

Why do we need Domain-Driven Design?

Domain-Driven Design is a concept that helps to reduce the overall complexity of a domain. Software solutions built using the Domain-Driven Design approach, tend to reflect the reality closer and enable the business to grow and expand faster in a reliable and predictable way.

{% hint style="success" %} With Domain-Driven Design you are delivering business value, not just an ordinary software. {% endhint %}

When to use Domain-Driven Design?

There are different opinions about the situations a DDD is appropriate and when you should use it.

There are several factors that make Domain-Driven Design shine. If you have everything in place you should expect good, if not great, results:

{% hint style="success" %} * you are building software for an established and already operating business * you have access to domain experts * you are passionate about what you are doing {% endhint %}

It is recommended to use other techniques, different from Domain Driven Design if:

• you are building a software solution for a totally new business. The argument behind this is that Domain-Driven Design relies on the experience and the know-how of the domain experts. It is very likely that you will invest a great amount of time designing models which are not useful. This for sure will lead you to a failure.
• you are building a concept/MVP solution for a new feature. It is better to do it the "quick-and-dirty" way so you could discover if the business concept will be successful or not. This will give you a deeper understanding of the problems you are trying to solve.

{% hint style="danger" %} * you are building a software solution for a totally new business * you are building a concept/MVP solution {% endhint %}

How to apply Domain-Driven Design?

• Find a domain expert!
• Strategic design
• Tactical design
• Fail fast
• Anticipate the steep learning curve