Domain-driven (DDD) is a business-oriented modeling method or architecture method.
Traditional data drivers are generally MVC architecture, which is a classic three-tier architecture, with business concentrated in the service layer. The consequence is that the service layer becomes more and more bloated as the business becomes more and more complex, while the controller and dao layers change very little, becoming an anemic model.
To put it bluntly, domain driver is to conduct business modeling and abstract the business to form the domain layer, which is the business model layer. Business-related operations are encapsulated into the domain layer, and the domain is decoupled from the traditional dao layer through the repository. The function of the service layer is only reserved for controlling business logic. ---Personal understanding of DDD.
The domain-driven complexity lies in the business modeling of the domain layer. The advantage of domain-driven is business isolation and easy splitting, but it cannot improve performance, or even the opposite! In addition, domain drivers are generally accompanied by CQRS to separate reading and writing and model them separately, which requires a much larger amount of code.
For complex systems, domain driving can bring many benefits, but for small projects, the traditional three-tier architecture is more advantageous, unless there are further plans for the future.
Domain-driven thinking has a natural fit with microservices, and it still needs to be learned. The key point is to learn the idea of business division modeling