ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

[MtAsuka]

エヴァンスのドメイン駆動設計は素朴派オブジェクト指向から続く流れにあるけど、オブジェクト指向分析設計を経ずにドメイン駆動設計に入った人は単に設計パターンとして捉えてそれに囚われすぎてる気がする。

[Magicant]

集約ルートや不変条件の話が出て来ない時点で残念ながら方向性が数十度ズレてる。手続きを内容ごとに整理するだけならサービスでいい

[kagehiens]

クラスの分け方はデータの記録形態と必ずしも一致させる必要はないが、混同されがちであるという話。／クラスと対応させるのを更新可能なビューにできたらベストではあるのだが、そうキレイにはまとまらんよね……。

[peketamin]

"注文金額を計算するための集約と、送料を計算するための集約とに分けて考えたほうがよさそうです。"/コレクションとアグリゲートは別ものなんだなあ

[xlc]

ドメイン駆動設計自体がわかりにくくてあやしいと思ってる。

[n314]

たぶんプログラムじゃなくて図で説明するから分かりにくいんじゃないだろうか。「こういう場合に不都合がある」っていうのはプログラムだとすぐ分かるよね。

[hamamuratakuo]

集約はロジックを整理するパターン→クラスの集約の設計は、永続化とは異なる関心事。ドメイン駆動設計を理解する基礎固めの一つとして、集約をデータ整合性ではなくロジックの置き場所の設計として考えてみましょう

[tasato-redhat]

すごいいいこと書いてある。

[turanukimaru]

言いたいことは解るし慣れてからでもいいがライフサイクルは重要。注文集約は注文確定時の届け先のコピーか発送記録を保持しなければならない。でないと注文後に届け先を変えたときにどこに発送したか分からなくなる

[Chisei]

読んだ

[yojik]

"クラスの集約はデータの扱い方の設計ではなく、ロジックの記述と整理するための設計パターンです。"

[a_suenami]

それなって感じだった（こなみかん）