Domain-Driven Design (DDD) is an approach to software development that emphasizes the importance of understanding the business domain and incorporating that understanding into the software design. DDD provides guidelines and patterns to help developers create well-structured, maintainable, and scalable software.
The main difference of DDD compared to other approaches, is grouping features vertically base on Domain.
For example,
- Features related to User domain will be put under User folders, like Create/Edit/View/Delete Users (Table Users), Transaction history of Users (Table Transactions), Leave off of Users (Table Holidays).etc. Which means, 1 Domain could handle queries/commands from many tables, related to that Domain.
- Features related to Organization domain will be put under Organization folders, like Create/Edit/View/Delete organization's information, organization's employees, finance of organization...
This approach may lead to duplicate code as they may query from the same DB source. Duplication queries/command in DDD is acceptable within a certain threshold, so the team must discuss and determine that feature belong to which Domain before implementation.
Infrastructure layer is where we implement the rest. For example: batch excuter, SQL query/command to DB, and Controller to receive API request/response.
This is a basic example, and in a real-world scenario, you would likely have more complex business logic, validation, and error handling. Additionally, you might use an ORM (Object-Relational Mapper) like Entity Framework for data access.
Note: The actual implementation might vary based on your specific requirements and the technologies you are using.