実践DDD本 第10章「集約」～トランザクション整合性を保つ境界～

• 実践DDD本 第9章「モジュール」～高凝集で疎結合にまとめる～

DDDにおける集約

　DDDにおける集約（Aggregates）とは、オブジェクトのまとまりを表し、整合性を保ちながらデータを更新する単位となります。通常はオブジェクトの集まりの「境界線」の意味で使われ、オブジェクト群の生成／読み込み／変更／保存といったライフサイクル管理が行われます。

外部から集約を操作できる「集約ルート」

　外部から集約を操作する場合、代表オブジェクトである「集約ルート（≒ルートエンティティ）」のみ参照することができます。集約ルートを操作することで集約全体の整合性を保ちながらデータを変更できます。

　上図の例では、注文に関わるオブジェクト群が集約の「境界線」となっています。操作をしたい場合「注文」という「集約ルート」に変更依頼をすることができます。集約内部にある「注文明細」や「配送先住所」といった集約ルート以外のオブジェクトに直接指示を出すことはありません。

集約が担う境界内の「整合性」

　集約はオブジェクト群の整合性の境界を保ちながらデータを更新します。整合性には以下の2つが存在しています。

• トランザクション整合性
• 結果整合性（4章「CQRSと結果整合性」参照）

　DDDの集約は、即時的な整合性である「トランザクション整合性」と同義です。このことから、トランザクションの分析をした後でなければ、集約の設計が適切かを判断できません。なお、トランザクションという言葉は使っていますが、特定のDBのトランザクション命令そのものではありません。あくまで（結果整合性とは対照的に）同期的に整合性を保つ必要性を表しています。

　上の注文例の場合、注文明細として100円の追加をした場合には、注文合計額にも100円が同時に加算された上で確定される必要があります。

IDDDのサンプルプロジェクトで考える集約

　それでは、SaaSOvationを例に集約について見ていきましょう。前回まで紹介してきた通り、アジャイルプロジェクトのサービスに関するモデリングを見ていきます。ここでは、各プロダクトは複数のバックログアイテム（課題）を持ちます。そしてスプリント（2週間などのタイムボックス期間）やリリース（デプロイ日）を持ちます。これらを集約の観点からモデリングしてみます。

巨大な集約の問題点

　まず、何も考慮せずにモデリングした場合、大きな集約ができ上がります。こうした大きい集約「プロダクト」を作成した場合、数千のバックログアイテム、スプリント、リリースオブジェクトを毎回メモリに読み込み、更新する必要があり、性能面で期待することはできません。

　モデリングは簡単ですが、この場合、実用に耐えません。複数のユーザーが同時に操作した場合に、トランザクションが衝突する可能性が非常に高いためです。通常、エンティティの実装を行う場合、楽観的並行性制御と呼ばれる手法がよく用いられます。この手法では、エンティティがバージョン番号を保持しており、なんらかの変更を行う度にバージョン番号を加算していきます。もし別のユーザーが集約を更新済みの場合、想定しているバージョン番号と異なるため、後から更新しようとしたユーザーがエラーとなります。そのため別のユーザーに更新された後の最新値を取得して、更新処理をやり直す必要があります。

小さな集約の特徴

　そこで、大きな集約の問題を回避するために、小さい集約を複数作成することにします。これまでひとつだった集約を複数に分解します。各集約それぞれに集約ルートが存在することになります。

　この例では、大きな集約を分割し、バックログアイテムの集約にフォーカスしています。プロダクト／リリース／スプリントといったエンティティは、別の集約のルートエンティティとしてモデリングしています。そして、他の集約ルートを直接参照するのではなく、識別子（ID）のみを参照しています。トランザクションは、集約を取り扱うアプリケーションサービス（11章）側で制御することになります。大きな集約と小さな集約の違いについて簡単に見てみましょう。

　このように、集約を小さくすることでトランザクションが衝突しなくなります。なお、要件を満たすだけの性能が出せるかは、実際のシナリオに基づいた検証を行う必要があります。参考までに、IDDD本の中では、ひとつの集約が144個のオブジェクトを保持することを試算し、ここでは問題ないと判断しています。