实现领域驱动设计 - 使用ABP框架 - 通用准则
在进入细节之前，让我们看看一些总体的 DDD 原则
数据库提供者 / ORM 无关性
领域和应用程序层应该与 ORM / 数据库提供程序 无关。它们应该只依赖于 Repository 接口，而 Repository 接口不使用任何 ORM 特定的对象
下面说明这一原则的主要原因:
- 为了使您的 领域/应用程序 独立于 基础设施，因为基础设施可能在将来更改，或者您可能需要支持第二种数据库类型
- 通过将基础设施细节隐藏在存储库后面，使您的 领域/应用程序 专注于业务代码。
- 使您的自动化测试更容易，因为在这种情况下您可以模拟存储库
根据这一原则，解决方案中的任何项目都没有引用EntityFrameworkCore项目，除了启动应用程序
关于数据库无关性原则的探讨
上述原因1,深深地影响了你的领域对象设计(尤其是实体关系)和应用程序代码。假设您正在使用 EF Core 与关系数据库。如果你想让你的应用在以后切换到 MongoDB ，你就不能使用一些非常有用的 EF Core 特性
例如:
- 你不能假设 Change Tracking，因为 MongoDB 不能这样做。因此，您总是需要显式地更新已更改的实体。
- 您不能对实体中的其他聚合使用 导航属性 (或集合)，因为这对于文档数据库是不可能的。更多信息请参见“规则:仅根据Id引用其他聚合”部分
如果你认为这些功能对你很重要，并且你永远不会偏离 EF Core，我们相信这一原则是值得延伸的。我们仍然建议使用 Repository 模式来隐藏基础设施细节。但你可以假设你在设计实体关系和编写应用程序代码时使用的是 EF Core。你甚至可以从你的应用层引用 EF Core 的 NuGet 包 来直接使用异步LINQ扩展方法，比如ToListAsync() (参见 Repositories 文档中的 IQueryable & Async 操作部分来获取更多信息)
表现层技术无关性
表现层技术(UI框架)是真实应用程序中变化最大的部分之一。在设计领域层和应用层时，完全不考虑表现层技术/框架是非常重要的。这一原则相对容易实现，而ABP的启动模板使之更加容易
在某些情况下，您可能需要在应用程序层和表示层中有重复的逻辑。例如，您可能需要在两个层中重复验证和授权检查。UI层中的检查主要是为了用户体验，而应用程序层和领域层中的检查是为了安全性和数据完整性。这是非常正常和必要的
关注状态变化,而不是报告
DDD关注领域对象如何变化和交互;如何创建实体并通过保持数据完整性/有效性和实现业务规则来更改其属性
DDD忽略报告和大规模查询。这并不意味着它们不重要。如果您的应用程序没有花哨的仪表板和报告，谁会使用它呢?然而，报告是另一个主题。您通常希望使用SQL Server的全部功能，甚至使用单独的数据源(如ElasticSearch)来进行报告。您将编写优化的查询、创建索引甚至存储过程(!)。您可以自由地做所有这些事情，只要您不将它们影响到您的业务逻辑
