Domain-Driven Design
In this article, I will summarize Domain-Driven Design, as far as I have read and understood.
Enjoy…
Domain: small clusters that are connected to each other in an application and form the business logic of the application.
Domain-Driven Design(DDD): a software development approach that deeply connects the ever-changing basic business rules in a world with complex requirements.
What does DDD solve?
DDD is an approach that was first put forward by Eric Evans and supported by Martin Fowler as in many other issues. Eric Evans argues that the problems in large and complex systems should be solved within their own domain by dividing them into domains. According to Eric Evans, most of these problems are caused by the fact that the business and technical teams don’t speak a common language and the software is not modeled correctly.
The main purpose of DDD is to produce software applications that are easily scalable, flexible, and highly available, providing rapid adaptation to rapidly changing requirements. According to DDD, the business rules of an application are logically distributed to the domains. While the modules most related to each other are kept on the same domain, other units are moved to different domains.
There are basic principles on which this approach is based. I say basic because of not all: