精读《领域驱动设计》：Cohesive Mechanism 内聚机制

核心：Cohesive Mechanism 内聚机制目的是解决描述性模型所提出来的一些复杂的计算问题。

那么首先必要的上下文：

如何保持领域模型的完整性如何保持领域模型的完整性如何保持领域模型的完整性描述如何通过Bounded Context使自己的领域模型保持完整，但是随着业务的不断发展模型也在不断的完善，模型本身会膨胀到我们难以控制。所以我们要时刻精简我们的模型，如何清晰的明确哪些是我们模型要解决的主要矛盾，即：“Core Domain”

Core Domain

核心领域，我们建模中亟待解决的主要矛盾

• 它内容应该是精炼的
• 它在工作中的优先级应该是最高的最先被解决的
• 它应该是趋于稳定的，因为Core Domain经常被变更很有可能是我们对模型理解不够

Generic Subdomain

一些和我们当前要解决的核心问题【Core Domain】的通用知识我们应该分离出去至少在设计Core Domain时候它们的优先级不高，属于次要矛盾。比如订单系统中的“用户”，它不属于订单系统的Core Domain，订单系统的Core Domain更应该是订单的状态、流转等信息

突出Core Domain的俩种方法

1. Domain Vision Statement-领域远景说明：它很类似我们上学时候总结文章的主要内容，应该简要指出我们当前核心要解决的问题主旨，以及我们模型的核心价值，与此无关的信息都不要提，也就是我们常说的痛点。
2. Highted Core：突出核心，Core Domain应该能很容易的被分辨出来，应该被团队所有人非常容易的理解

Cohesive Mechanism 内聚机制

如果模型包含了很复杂、专业的算法，集成在模型中可能导致Core Domain的混乱那么我们可以把算法抽象出去并且提供api给Core Domain。很类似Generic Subdomain（看最下面的拓展注释），它俩的区别可能Cohesive Mechanism只是封装了算法而不是模型。

在《领域驱动设计》第15.6节中，cohesive mechanism是指一组相关的元素在一起协同工作，以实现某个目标。

这些元素之间的协作关系应该是高度内聚的，即它们应该紧密地关联在一起，以实现一个共同的目标。作者提出了三种cohesive mechanism：聚合、组合和引用。

具体的例子：

当我们设计一个电商平台时，可以使用聚合、组合和引用来描述不同的领域对象之间的关系。

1. 聚合：订单(Order)和订单项(OrderItem)之间的关系可以用聚合来描述。一个订单包含多个订单项，但是订单项可以独立于订单存在。
2. 组合：商品(Product)和商品规格(ProductSpecification)之间的关系可以用组合来描述。一个商品由多个商品规格组成，这些商品规格必须一起工作才能实现商品的功能。
3. 引用：订单项(OrderItem)和商品(Product)之间的关系可以用引用来描述。一个订单项引用了一个商品，但是订单项并不拥有该商品。

ABP框架是如何运用Cohesive mechanism？

ABP框架是一个基于领域驱动设计的企业应用开发框架，它在设计中运用了cohesive mechanism来帮助开发者构建高内聚的领域模型。

在ABP框架中，聚合根(Aggregate Root)是一个非常重要的概念，它用于描述一组相关的对象，在一起协同工作以实现某个目标。聚合根是一种特殊的领域对象，它具有唯一的标识符，并且可以包含其他领域对象。

ABP框架还使用了仓储(Repository)来管理聚合根和其他领域对象。仓储是一种用于持久化和检索领域对象的机制，它可以帮助开发者将领域对象从数据存储中解耦出来。

此外，ABP框架还使用了依赖注入(Dependency Injection)来管理对象之间的依赖关系。依赖注入是一种将对象之间的依赖关系从代码中解耦出来的机制，它可以帮助开发者构建高内聚、低耦合的应用程序。

通过使用这些cohesive mechanism，ABP框架可以帮助开发者构建高内聚、低耦合的领域模型，并使得应用程序更加易于理解和维护。

看一下别人的理解：

Sometimes when we are refactoring our domain model, a cohesive mechanism emerges. It could be a concept or pattern that is general knowledge in software development like graph operations or something like a rule engine.

The cohesive mechanism should be factored out of the core domain and put into a supporting module. This simplifies the core domain, and most developers can understand the cohesive mechanism or look it up at least.

In contrast to generic sub-domains which subtract a part of the core domain, cohesive mechanisms can be used to encapsulate complex logic. Both patterns leave behind a more coherent and simplified core dom

个人总结是：

内聚机制可用于封装复杂的逻辑。这两种模式都会留下一个更连贯和简化的核心领域。比如ABP的DI机制，使得我们更关心依赖 或者说 只关心于领域？DI机制是封装了复杂了依赖注入具体实现。

内聚机制是一种概念，不是某一种具体实现。

拓展注释：

在领域驱动设计中，Subdomain是指一个领域模型中的子领域，它通常与整个领域模型的其他部分有明显的区别，并且可能有自己的专门术语和规则。

Generic Subdomain是指一个通用的、常见的子领域，它在许多不同的领域模型中都会出现，并且具有相似的特征和需求。例如，用户管理、权限管理、日志记录等都是通用的子领域。

在领域驱动设计中，对于这些通用子领域，我们可以使用通用解决方案来处理它们，而不必在每个领域模型中都重新实现一遍。这样可以提高开发效率，并且使得代码更加易于维护。

通用解决方案可以是一些通用的类库、框架或者模块，它们可以被多个领域模型所共享。例如，ASP.NET Identity就是一个用于处理用户管理和权限管理的通用解决方案，它可以被多个ASP.NET应用程序所共享。

reference：

如何精炼领域模型 | liuhao163.github.io

DDD Concepts and Patterns – Distillation of the core domain | Opus Software AG