使用ASP.NET Core和EF Core实现模块化单体DDD架构的经验 – thereformed

21-02-09 banq

本文是关于我在使用ASP.NET Core和EF Core的小型但复杂的应用程序上使用模块化单体/整体结构和域驱动设计(DDD)方法的经验。这不是有关模块化单体架构或DDD的入门知识(但每个链接都有很好的摘要),但我对每种方法的优缺点都有自己的看法。

主要心得:

  • 模块化Monolith单体体系结构是将代码分解为应用程序所需的每个功能的独立模块(C#项目)。每个模块仅链接到专门提供其所需服务的其他模块。
  • 领域驱动设计(DDD)是一种用于理解,设计和构建软件应用程序的单体方法。
  • 我使用这两种架构方法使用ASP.NET Core和EF Core构建应用程序。该应用程序完成后,我分析了每种方法在时间压力下如何工作。
  • 这是我第一次使用Modular Monolith模块化单体架构,但它以鲜艳的色彩出现。该代码结构由22个项目组成,并且每个项目(ASP.NET Core前端除外)都专注于应用程序功能的一个特定部分。
  • 我已经使用了很多DDD,并且正如我期望的那样,它在该应用程序中确实运行良好。这些类(DDD称为实体)具有有意义的命名方法来更新数据,因此很容易理解。
  • 我也向您介绍每种方法的好,坏和可能的“裂缝”。

 

一个模块化的单体架构

这就是在构建和部署单个大而整体应用程序的方法,但是以模块方式。这种方法可以减少模块的依赖性,例如可以增强/更改模块而不会影响其他模块。下图显示了9个项目,这些项目在系统中实现了两个不同的功能。请注意,他们只有一个常见的(小型)项目。

模块化整体式方法比普通整体式方法的优势在于:

  • 降低复杂性:每个模块仅链接到其特定需要的代码。
  • 易于重构:更换模块对其他模块的影响很小或没有影响。
  • 对团队更有利:使开发人员更容易处理代码的不同部分。

 

域驱动设计(DDD)

DDD表示您的实体类必须控制其包含的数据;因此,所有属性对于用于创建或更改实体类中的数据的构造函数/方法都是只读的。这样,实体类的构造函数/方法可以确保创建/更新遵循该实体的业务规则。

DDD的另一个术语是有界上下文,它是将您的应用程序分成不同的部分,并且在有界上下文之间进行非常受控的交互。例如,我的应用程序是一个电子商务网站销售书,并且我可以看到书的显示与订购某些书的客户不同。存在共享数据(例如产品编号和出售书的价格),但它们是分开的。

下图显示了如何在数据库级别分离书籍的显示和书籍的顺序。

使用DDD的有界上下文技术,Book有界上下文可以在不影响Orders有界上下文的情况下更改其数据(产品代码和销售价格除外),并且Orders代码不能在Books有界上下文中进行任何更改。

与非DDD方法相比,DDD的优点是:

  • 受保护的业务规则:实体类方法包含大多数业务逻辑。
  • 更明显的是:实体类包含具有有意义的命名要调用的方法。
  • 降低复杂性:有界上下文将应用程序分成多个单独的部分。

更多点击标题见原文

 

                   

1
猜你喜欢