实现领域驱动设计 - 使用ABP框架 - 通用准则
阅读原文时间:2022年06月23日阅读:1

在进入细节之前,让我们看看一些总体的 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)来进行报告。您将编写优化的查询、创建索引甚至存储过程(!)。您可以自由地做所有这些事情,只要您不将它们影响到您的业务逻辑