3.4 Common Principles 常用原则

3.4 Common Principles 常用原则

Before going into details, let's see some overall DDD principles;
在讨论细节之前，让我们看看DDD的一些总体原则。

3.4.1 Database Provider / ORM Independence 数据驱动程序/ORM的独立性

The domain and the application layers should be ORM / Database Provider agnostic. They should only depend on the Repository interfaces and the Repository interfaces don't use any ORM specific objects.
领域层和应用层应该是与ORM/数据库提供者无关的。它们应该只依赖于存储库的接口，存储库的接口不使用任何ORM的具体对象。
Here, the main reasons of this principle;
这一原则的主要原因如下：

1. To make your domain/application infrastructure independent since the infrastructure may change in the future or you may need to support a second database type later.
   为了使你的领域层/应用层的基础框架结构独立开来，因为基础框架结构在未来可能会改变，或者你以后可能需要支持第二个数据库类型。
2. To make your domain/application focus on the business code by hiding the infrastructure details behind the repositories.
   为了使你的领域层/应用层专注于业务逻辑代码，通过隐藏存储库之后的基础框架结构的细节的方式。
3. To make your automated tests easier since you can mock the repositories in this case.
   为了使你的自动化测试更容易，因为在这种情况下你可以模拟存储库。

As a respect to this principle, none of the projects in the solution has reference to the EntityFrameworkCore project, except the startup application.
作为对这一原则的尊重，除了启动应用程序外，解决方案中的所有项目都没有引用EntityFrameworkCore项目。

3.4.2 Discussion About the Database Independence Principle 关于数据库独立原则的讨论

Especially, the reason 1 deeply effects your domain object design (especially, the entity relations) and application code.Assume that you are using Entity Framework Core with a relational database. If you are willing to make your application switchable to MongoDB later, you can't use some very useful EF Core features.
特别是原因1深深地影响了你的领域对象设计（特别是，实体关系）和应用程序代码。假设你正在使用关系型数据库的Entity Framework Core。如果你以后想让你的应用程序可以切换到MongoDB，你就不能使用一些非常有用的EF Core的功能特性。
Examples;例如：

• You can't assume Change Tracking since MongoDB provider can't do it. So, you always need to explicitly update the changed entities.
  你无法设定变化追踪，因为MongoDB驱动程序不能做到这一点。所以，你总是需要显式地更新变化的实体。
• You can't use Navigation Properties (or Collections) to other Aggregates in your entities since this is not possible for a Document Database. See the "Rule: Reference Other Aggregates Only By Id" section for more info.
  你不能对实体中的其他聚合体使用导航属性（或集合），因为这在文件型数据库中是不可能的。更多信息请参见 "规则：仅通过标识ID引用其他聚合体 "部分。

If you think such features are important for you and you will never stray from the EF Core, we believe that it is worth stretching this principle. We still suggest to use the repository pattern to hide the infrastructure details. But you can assume that you are using EF Core while designing your entity relations and writing your application code. You can even reference to the EF Core NuGet Package from your application layer to be able to directly use the asynchronous LINQ extension methods, like ToListAsync() (see the IQueryable & Async Operations section in the Repositories document for more info).
如果你认为这样的功能对你很重要，而且你永远不会远离EF Core，我们认为沿用这个原则是值得的。我们仍然建议使用存储库模式来隐藏基础设施的细节。但你可以假设你在设计实体关系和编写应用程序代码时使用的是EF Core。你甚至可以从你的应用层引用EF Core NuGet包，以便能够直接使用异步LINQ的扩展方法，比如ToListAsync()（详见Repositories文档中的IQueryable & Async Operations部分）。

3.4.3 Presentation Technology Agnostic 表现层技术无关性

The presentation technology (UI Framework) is one of the most changed parts of a real world application. It is very important to design the Domain and Application Layers to be completely unaware of the presentation technology/framework. This principle is relatively easy to implement and ABP's startup template makes it even easier.
表现层技术（UI框架）是现实世界应用中变化最大部分的其中之一。将领域层和应用层设计成完全不知道表现层技术/框架是非常重要的。这一原则相对容易实现，ABP的启动模板使其更加容易。
In some cases, you may need to have duplicate logic in the application and presentation layers. For example, you may need to duplicate the validation and authorization checks in both layers. The checks in the UI layer is mostly for user experience while checks in the application and domain layers are for security and data integrity. That's perfectly normal and necessary.
在某些情况下，你可能需要在应用层和表现层编写重复的逻辑。例如，你可能需要在这两层中重复进行验证和授权方面的检查。UI层的检查主要是为了用户体验，而应用和领域层的检查是为了安全和数据完整性。这是很正常的，也是必要的。

3.4.4 Focus on the State Changes, Not Reporting 专注于状态的变化，而不是报告

DDD focuses on how the domain objects changes and interactions; How to create an entity and change its properties by preserving the data integrity/validity and implementing the business rules.
DDD的重点是领域对象如何变化和交互；如何通过保持数据的完整性/有效性和实现业务规则的方式来创建一个实体和改变其属性。
DDD ignores reporting and mass querying. That doesn't mean they are not important. If your application doesn't have fancy dashboards and reports, who would use it? However, reporting is another topic. You typically want to use the full power of the SQL Server or even use a separate data source (like ElasticSearch) for reporting purpose. 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 infect them into your business logic.
DDD忽略了报表和大规模查询。这并不意味着它们不重要。如果你的应用程序没有花哨的仪表盘和报告，谁会使用它？然而，报表是另一个话题。你通常希望使用SQL Server的全部功能，甚至使用一个单独的数据源（如ElasticSearch）来实现报表用途。你会编写优化的查询，创建索引，甚至存储过程（！）。你可以自由地做所有这些事情，只要你不把它们带到你的业务逻辑中。