When to use Domain Driven Design

I’ve noticed that most of developers go for Domain Driven Design at their first choice. Well, the question is : “Do I have to solve ALL the problems through domain driven design?”.

While this concept (domain driven design) is good, you shall not use it to solve every problem!

in short, You shall use it when the complexity of your project is in logic. But what does it mean exactly? Yes you always hear this: “use it when you have complexity in your domain”. Yet you don’t know what it means.

The fact is when we are trying to model a problem, There are 3 scenarios we may face:

  • Our software is UI driven!
  • The software is data driven.
  • The software is domain driven

UI driven

UI driven software is a software with a complex  behavior of the UI elements, Such as drag and drop, smart elements, animated ones and… If you take a deep look into such software, a complex logic is not implemented behind the scene.

You deal mostly with UI elements. You write lots of code to coordinate UI. You test the UI mostly, etc…
Now let’s take domain driven design into consideration. You shall be focused on UI while you focus mostly on domain. A domain that in fact does not exist at all! Or if exist, it is made of some simple code. Is it wise to take your focus out of the main problem and put it on somewhere which is not important?
Have it in mind that all those standards are to help you put the most effort on the most complex parts of your software.

Data Driven

The ‘CRUD’ scenario on the other hand is a bit different. A simple CRUD is not complex at all. When all you have to do is to insert an object into database and fetch it later, Why you should bother with Domain Driven Design? Knowing the fact that DDD adds up lots of code into your solution.
It means that some times you may have a project with multiply layers in different technologies.
You usually have some basic information in your software. such as simple crud operation to insert,update some basic info. A good example would be “filling a profile”. What you have do is to fill a form and submit it into Database. Does it really require a complex domain?

So the best approach is to break it into a separate layer and use simple codes for the “CRUD” operation. No DDD is required at all.

Domain Driven

A complex domain on the other hand is a different scenario. DDD helps you to break a complex logic into smaller steps and solve them one by one. As well as trying to seperate the concerns.

relatedAggregates and Facade pattern

While using DDD you 100% focus on the problem. The DB technology,the ORM and… comes later and you do not concern yourself with that problem at this point.
The fact that DDD works best with onion architecture is exactly because of that “Seperation of concerns” I mentioned.

So the next time you wanted to design a software, keep in mind that you are not forced to use DDD on all of the layers!
Just break your application into separate layers with different design techniques.

Leave a Reply

Your email address will not be published. Required fields are marked *