实现领域驱动设计 - 使用ABP框架 - 通用准则

在进入细节之前,让我们看看一些总体的 DDD 原则

数据库提供者 / ORM 无关性

领域和应用程序层应该与 ORM / 数据库提供程序 无关。它们应该只依赖于 Repository 接口,而 Repository 接口不使用任何 ORM 特定的对象

下面说明这一原则的主要原因:

  1. 为了使您的 领域/应用程序 独立于 基础设施,因为基础设施可能在将来更改,或者您可能需要支持第二种数据库类型
  2. 通过将基础设施细节隐藏在存储库后面,使您的 领域/应用程序 专注于业务代码。
  3. 使您的自动化测试更容易,因为在这种情况下您可以模拟存储库

根据这一原则,解决方案中的任何项目都没有引用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)来进行报告。您将编写优化的查询、创建索引甚至存储过程(!)。您可以自由地做所有这些事情,只要您不将它们影响到您的业务逻辑

posted @ 2022-06-23 09:33  Broadm  阅读(147)  评论(0编辑  收藏  举报