ドメイン駆動設計(DDD)ってなに？第3回：集約と集約ルートってなに？受付窓口で考えてみた

前回までで、「エンティティ」と「値オブジェクト」の違いをちょっとずつ整理してきました。
今回は、それらのモデルたちが実際にどうやってひとまとまりになって動いてるのか？について調べてみたメモです。

まず「集約」ってなんだっけ？

前回までで見てきたように、ドメインにはいろんな情報が登場します。
たとえばECサイトなら：

• 商品
• 注文アイテム
• 合計金額
• 配送先
• 注文ステータス

これらをバラバラに操作してると、整合性が崩れて事故のもとになります。
（例：商品は追加されたのに合計金額が更新されてない、みたいな）

なので、「これらはひとかたまりで管理しよう！」という考え方があるそうで、
DDDではこの「一貫性のあるまとまり」のことを**集約（Aggregate）**と呼ぶみたいです。

そして「集約ルート」＝この集まりの受付窓口

じゃあこの集まりをどこから操作するのか？

たとえば、注文アイテムを追加したり、配送先を変更したりする操作を、
それぞれバラバラに直接やってたらまた事故が起きるわけで…。

そこで登場するのが「集約ルート（Aggregate Root）」。
これは、この集まりの出入り口（＝受付窓口）みたいな存在です。

たとえ話で考えると…

ビルの1階にある受付窓口みたいなものです。

「中のことを何かしたいなら、まずここを通してください」
という責任の境界線みたいな役割。

たとえば「注文と注文アイテム」

ECサイトで「注文（Order）」と「注文アイテム（OrderItem）」があるとします。

• この注文全体のかたまりが「集約」
• その中で外とやり取りする窓口が「集約ルート」＝Order

たとえばこんな操作は、全部このルートを通してやるようにする：

• アイテムの追加
• 合計金額の再計算
• 注文のキャンセル

→ そうすることで、ルールの漏れや整合性の破綻を防げる。

集約ルートの中は、勝手にさわらせない

DDDの原則として、

集約の中のエンティティや値オブジェクトに、外から直接アクセスするのはNG

というルールがあるそうです。
あくまで「すべての操作はルートを通してやってね」という決まり。

まとめ

調べてみると、「集約」というのは一つの目的のために、いくつかの情報をまとめた“部品の集合体”。そして「集約ルート」は、その集まりの出入り口であり、責任を持つ窓口のような存在でした。

操作が分散してしまうと、何がいつ変更されたのか、どこでチェックするのかがわからなくなる。
そんな混乱を防ぐために、「この一塊はこの人が面倒見ます！」という仕組みが、DDDの中で大事になってくるんだな〜と納得しました。

次は、その集約ルートたちを勝手に生やされないようにする仕組み――
「🧳ファクトリ（認証工場）」について調べてみます！

→ 続き：「ファクトリってなに？認証工場で考える」に続きます！