Before entering the details , Let's look at some general DDD principle
Database providers / ORM Irrelevance
The domain and application layers should be aligned with ORM / Database provider irrelevant . They should only depend on Repository Interface , and Repository The interface does not use any ORM Specific object
Here are the main reasons for this principle :
- In order to make your field / Applications Independent of infrastructure , Because the infrastructure may change in the future , Or you may need to support the second database type
- By hiding infrastructure details behind the repository , Make your field / Applications Focus on business code .
- Make your automated testing easier , Because in this case you can emulate the repository
According to this principle , No project in the solution is referenced EntityFrameworkCore project , In addition to starting the application
Discussion on the principle of database independence
Above reasons 1, Deeply influenced your domain object design ( Especially the entity relationship ) And application code . Suppose you are using it EF Core And relational databases . If you want your app to switch to MongoDB , You can't use something very useful EF Core characteristic
for example :
- You can't assume Change Tracking, because MongoDB You can't do that . therefore , You always need to explicitly update changed entities .
- You cannot use... For other aggregations in an entity Navigation properties ( Or set ), Because this is impossible for a document database . For more information, see “ The rules : Only according to Id Reference other aggregations ” part
If you think these functions are important to you , And you will never deviate EF Core, We believe that this principle is worth extending . We still recommend using Repository Patterns to hide infrastructure details . But you can assume that you are designing entity relationships and writing application code using EF Core. You can even reference... From your application layer EF Core Of NuGet package To use asynchronism directly LINQ Extension method , such as ToListAsync() ( See Repositories In document IQueryable & Async Operation section for more information )
Presentation layer technology independence
Presentation layer technology (UI frame ) Is one of the most varied parts of a real application . When designing domain layer and application layer , Completely regardless of presentation layer technology / The framework is very important . This principle is relatively easy to implement , and ABP The startup template of makes it easier
In some cases , You may need to have duplicate logic in the application and presentation layers . for example , You may need to repeat authentication and authorization checks in two layers .UI Checking in the layer is mainly for the user experience , The checks in the application layer and the domain layer are for security and data integrity . It's very normal and necessary
Focus on state changes , Instead of reporting
DDD Focus on how domain objects change and interact ; How to create entities and maintain data integrity / Validation and implementation of business rules to change their properties
DDD Ignore reports and large-scale queries . This does not mean that they are not important . If your application doesn't have fancy dashboards and reports , Who would use it ? However , Reports are another topic . You usually want to use SQL Server All the functions of , Even use a separate data source ( Such as ElasticSearch) To report . You will write optimized queries 、 Create indexes and even stored procedures (!). You are free to do all these things , As long as you don't affect your business logic
