UML：
集約関係：オブジェクトは、部材の一体部分であるが、メンバオブジェクトは全体として物体から独立して存在することができます。
車（自動車）とエンジン（エンジン）、タイヤ（車輪）、ランプ（光）重合の関係との関係、エンジン、タイヤ、車のライトが他の車のエンジンに変更するには、例えば、から存在していてもよいですことができます。
関係を組み合わせる：全体のオブジェクトが存在しないいったん関係と組み合わせて、全体的な関係の不可欠な部分であるが、オブジェクトは、オブジェクトのメンバーのライフサイクルを制御することができた、何のメンバーオブジェクトが存在しない、全体的なオブジェクトとメンバーの間で持つオブジェクト総死亡と生徒の関係。
したがって、重合とほとんど差の組み合わせである：一部のライフサイクル全体、すなわちオブジェクトは全体としてオブジェクトとは別に存在することができるかどうかを全体ダイ部材の後、同じです。
DDDの集約関係は：
全体のうち一部にライフサイクル全体の死と一致強調し、無意味になり、また、関係の不可欠な部分であると。したがって、定義によりDDD重合と組み合わせ関係がUMLで一貫しています。
上記の定義によると、我々は典型的な例は、会社と部門間の関係で分析します。
UML角：
1、会社の部門の複数の、全体的な関係が成立していると部分;
2、及びセクタは、他の企業からの会社に追加することができません。
したがって、組み合わせは、UMLの関係、何の問題に属している必要があります。
ビューのDDDポイント：
UMLベースの視点、企業や部門は、関係の組み合わせに属するが、それは部門がそれ以下の企業で重合されるべきかどうかDDDにありますか？私の見解では、そのもののライフサイクルから、セクターことはできません、本当に会社から外れています。
しかし、DDD集計デザインの要因は、次のような、より豊富になると考えられます。
- ニーズと有界コンテキストにDDD強調、それは我々が最初に現在のニーズと状況が何であるかを判断しなければならない前に、それはニーズやコンテキストモデルに基づいてモデル化されます、です。
- 強い懸念の全体の一部であるかどうかを、現在の文脈では、
- 全体と部分との間に任意のルールの不変性はあります。
- サービス全体のシーンは、操作部と一致するか否かを操作。
- 重合の全体的な数の一部が大きすぎると、パフォーマンスの問題は、それが重合、小さな集約原則を考慮しています。
- 一貫性、我々は、オブジェクトが、削除された複数のアグリゲーションサービスエリアによって作成された相乗効果を完了するなど、技術の一貫性を解決するために上がることができます一緒に複数の重合のための別のデザインの今後提示することである場合でも、システムを設計しました、変更、およびデータベーストランザクションを介して厳密強い整合性を確保します。
- DDDフィールドモデリングドメインの概念は、とても自然にルートを集約企業が存在しますので、ドメインモデル、おそらくいない会社ではなく、唯一の部門は、同社はまた、ライン上のトップレベルの部門として見られている、抽象的になりますA;
だから、全体的な削除を導出するための設計時にDDD重合、一部のみから無意味（オブジェクト間すなわちライフサイクル）になります場合は、その時点で、それはあまりにも薄い検討し、可能性が高いです重合の不合理なデザイン。
これは、ビジネスニーズの深刻な分析、ビジネスルールの不変性の無い分析、合理的なフィールドの無い抽象的な概念、ソフトウェアの無いパフォーマンスアプリケーションのオブジェクト指向設計の原則ではありません。
私は、これはなぜこれほど難しいアップなぜDDD集計デザイン上の理由だと思います。
したがって、需要が不明であるため、結論はより多くのそのような場合で、集計デザインすることはできません、我々はそれに驚いていませんか？何の答えはありません:)