Domain Driven Design Advantages and Disadvantages

In today's blog post, I will be discussing what domain driven design is along with it's advantages and disadvantages.

Domain Driven Design

The term "Domain Driven Design" was coined by Eric Evans in 2003 in his book titled "Domain Driven Design".

The Domain Driven Design (DDD) is an approach to software design which makes us focus on the heart of the application i.e. complexity of the business domain rather than technical details. DDD contains a set of patterns for building enterprise applications from the domain model out.

Advantages of DDD

Here are the advantages of using Domain Driven Design:

i) Patterns

DDD gives us the principles and patterns to solve difficult problems in software as well as sometimes in business. These patterns have been successfully used to solve complex problems.

ii) History of Success

It has a history of success with complex projects. It aligns very well with the experience of developers and successful software applications already built.

iii) Clear Code

It helps us write clear and testable code that represents the domain. The code is more focused and concise

iv) Better Understanding

It helps us understand client needs better.

What It Involves

To look at the Domain Driven Design from a high level, here are a few critical pieces which are important for us to successfully follow DDD methodologies:

i) Interaction with Domain Experts 

There is a lot of back and forth interaction with Domain Experts. The communication between the developers and domain experts is critical to the success of this methodology and our software. We as developers need to understand their terminologies, how they want to use the system and their pain points.

ii) Focus on part of Domain

Since the domain is complex, we need to divide it into sub-domains. By doing this, we are keeping the conversation focused to a specific sub-domain at a time. This leads to better understanding on both sides.

iii) Focus on part of Domain (again;)

During development too, the focus is on one sub-domain at a time. It helps the modeling and implementing of sub-domain efficiently and directly ties into separation of concerns principles.

Advantages of DDD to Code

If we follow Domain Driven Design, the resultant code also has a few advantages:

i) Supple

By following DDD, the code is very flexible and will be easier to change and extend.

ii) Solving Customer Problem

The resultant code is generally much more close to customer's vision and perspective of the problem.

iii) Divide and Conquer

Since we are breaking the complex problem into smaller pieces, the resultant code is also easier to write and read. It is much better organized and it should have fewer issues and should be easier to test.

iv) Patterns to Leverage

Even if we don't use DDD by the word, it still helps us to see many great patterns to leverage.

Disadvantages of DDD

DDD comes with a lot of advantages. However, there are a few disadvantages as well:

i) Only if Domain is Complex

The real benefit of DDD shows up only if the domain is complex. If the domain is simple, then DDD might be an overkill.

ii) Time Consuming Upfront

The developers have to spend a lot of time with domain experts to understand the domain thoroughly. This can be time consuming on both ends. Also, deciding the sub domains and system boundaries can also take lot of time.

iii) High Learning Curve

DDD has a high learning curve initially. Getting used to this new way of thinking might be painful at first but I think we as developers do like to give ourselves pain :P

Conclusion

Domain Driven Design helps us focus on the client problem and guides us in the direction of solving it using divide and conquer technique. We will be delving deeper into DDD in subsequent blog posts.

References:
Domain Driven Design book By Eric Evans