As a developer, we love to write code which leads us to jump on code and start building the software. But you can’t build software if you don’t understand the client’s needs. Domain Driven Design puts more emphasis to work with your client as a full partner. The ultimate goal is to solve complex business problems.
What is Domain Driven Design?
Domain Driven Design provides principle and pattern which helps us tackle complex business problems also it gives us clear testable codes that represents the domain. Eric Evans in his books “Tackling Complexity in the Heart of Software” emphasized these things:-
- Interact with Domain experts not only just for the requirement gathering but also to the extend at much greater length.
- The focus of a single subdomain at a time – Consider you are building an ECommerce website that can have several parts like product warehousing, Order Management, Payment, Notification, etc. Each of these tasks is a complex subdomain. Many of the subdomains might not have much interaction with each other. But how many applications are created to do many things at once then adding additional things will become more and more complex.
With Domain Driven Design you will divide and conquer, by separating problems into various sub-domain that’s why term modeling is very important in DDD and refers to how you decypher and design each subdomain. - Implementation of Subdomains- The focus should be on the subdomains, the problems you are trying to solve with your software.
Please note: The term problem here is the business problem, not the implementation problem or infrastructure concerns.
Benefits of DDD
- Flexible
- Well organized and easily tested code.
- Separation of Concern
Drawbacks
- Time and Effort to discuss and model the problem with domain expert
- It’s a learning curve that involves new principles, new patterns, and new process
Conclusion
While DDD provides many technical benefits such as maintainability but it should be applied to only complex domains like if your application is doing CRUD operations then it doesn’t make sense to use DDD. It would be waste of time and effort.
Also, remember that DDD is for the complex domains, not the technical complexity. If your domain is simple but you have lots of technical complexity then also in this case DDD is not the correct path.
If you want to read more about the DDD, I recommend to check Eric Evan book.
Hope you like the read. Happy Coding!
