本文是关于我在使用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的优点是：
- 受保护的业务规则：实体类方法包含大多数业务逻辑。
- 更明显的是：实体类包含具有有意义的命名要调用的方法。
- 降低复杂性：有界上下文将应用程序分成多个单独的部分。
更多点击标题见原文