核心：Cohesive Mechanism 内聚机制目的是解决描述性模型所提出来的一些复杂的计算问题。
那么首先必要的上下文：
如何保持领域模型的完整性如何保持领域模型的完整性如何保持领域模型的完整性描述如何通过Bounded Context使自己的领域模型保持完整，但是随着业务的不断发展模型也在不断的完善，模型本身会膨胀到我们难以控制。所以我们要时刻精简我们的模型，如何清晰的明确哪些是我们模型要解决的主要矛盾，即：“Core Domain”
Core Domain
核心领域，我们建模中亟待解决的主要矛盾
- 它内容应该是精炼的
- 它在工作中的优先级应该是最高的最先被解决的
- 它应该是趋于稳定的，因为Core Domain经常被变更很有可能是我们对模型理解不够
Generic Subdomain
一些和我们当前要解决的核心问题【Core Domain】的通用知识我们应该分离出去至少在设计Core Domain时候它们的优先级不高，属于次要矛盾。比如订单系统中的“用户”，它不属于订单系统的Core Domain，订单系统的Core Domain更应该是订单的状态、流转等信息
突出Core Domain的俩种方法
- Domain Vision Statement-领域远景说明：它很类似我们上学时候总结文章的主要内容，应该简要指出我们当前核心要解决的问题主旨，以及我们模型的核心价值，与此无关的信息都不要提，也就是我们常说的痛点。
- Highted Core：突出核心，Core Domain应该能很容易的被分辨出来，应该被团队所有人非常容易的理解
Cohesive Mechanism 内聚机制
モデルに非常に複雑で専門的なアルゴリズムが含まれており、モデルへの統合がコア ドメインで混乱を引き起こす可能性がある場合は、アルゴリズムを抽象化してAPI をコア ドメインに提供できます。これは Generic Subdomain とよく似ています (下部の拡張コメントを参照) 両者の違いは、Cohesive Mechanism がモデルではなくアルゴリズムを単にカプセル化していることかもしれません。
「ドメイン駆動設計」のセクション 15.6 では、凝集メカニズムとは、特定の目標を達成するために連携して機能する一連の関連要素を指します。
これらの要素間の協力関係は、高度に凝集している必要があります。つまり、共通の目標を達成するために密接に関連している必要があります。著者は、集約、結合、参照という 3 つの凝集メカニズムを提案しました。
具体的な例:
電子商取引プラットフォームを設計するとき、集約、組み合わせ、参照を使用して、さまざまなフィールドのオブジェクト間の関係を記述することができます。
- 集計: 注文 (Order) と注文項目 (OrderItem) の間の関係は、集計によって説明できます。オーダーには複数の明細項目が含まれますが、明細項目はオーダーとは独立して存在できます。
- 組み合わせ：製品（Product）と製品仕様（ProductSpecific）の関係を組み合わせで記述できます。製品は、製品の機能を達成するために連携する必要がある複数の製品仕様で構成されています。
- リファレンス: リファレンスを使用して、注文アイテム (OrderItem) と商品 (Product) の関係を記述できます。ラインアイテムはアイテムを参照していますが、ラインアイテムはアイテムを所有していません。
ABP フレームワークは Cohesive メカニズムをどのように使用しますか?
ABP フレームワークは、ドメイン駆動設計に基づくエンタープライズ アプリケーション開発フレームワークであり、設計に凝集メカニズムを使用して、開発者が凝集性の高いドメイン モデルを構築できるようにします。
在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.
コア ドメインの一部を差し引く汎用サブドメインとは対照的に、凝集メカニズムを使用して複雑なロジックをカプセル化できます。どちらのパターンも、より一貫性があり単純化されたコア ダムを残します。
私の個人的な要約は次のとおりです。
凝集メカニズムを使用して、複雑なロジックをカプセル化できます。どちらのモデルも、より一貫性があり、簡素化されたコア領域を残します。たとえば、ABP の DI メカニズムにより、依存関係をより重視するようになりますか、それともドメインのみを重視するようになりますか? DI メカニズムは、依存関係注入の複雑な実装をカプセル化します。
凝集メカニズムは概念であり、特定の実装ではありません。
拡張メモ:
ドメイン駆動設計では、サブドメインはドメイン モデル内のサブドメインを指します。これは通常、ドメイン モデル全体の他の部分とは大きく異なり、独自の専門用語やルールがある場合があります。
汎用サブドメインとは、多くの異なるドメイン モデルに現れ、同様の特性と要件を持つ、一般的な共通のサブドメインを指します。たとえば、ユーザー管理、権限管理、ログ記録などはすべて共通のサブフィールドです。
ドメイン駆動設計では、これらの共通のサブドメインに対して、すべてのドメイン モデルで再実装することなく、共通のソリューションを使用してそれらを処理できます。これにより、開発効率が向上し、コードの保守が容易になります。
共通のソリューションは、複数のドメイン モデルで共有できるいくつかの共通のクラス ライブラリ、フレームワーク、またはモジュールです。たとえば、ASP.NET Identity は、複数の ASP.NET アプリケーションで共有できるユーザー管理と権利管理を処理するための汎用ソリューションです。
参照：