"Kill the Aggregate" ～ 集約を排除する5つの理由 イベントソーシング・CQRS 勉強会 #3 2025年 7月 11日 株式会社ジェイテックジャパン 川江貴志 

"Kill the Aggregate"（集約の排除） ここで言う集約は、DDD (ドメイン駆動設計) の集約 Sara Pellegrini 氏によって提唱 https://sara.event-thinking.io/ https://www.youtube.com/watch?v=DhhxKoOpJe0 https://www.youtube.com/watch?v=wXt54BawI-8 Pellegrini 氏の主張 "Kill the Aggregate!"（集約を無くしてしまおう！） 

集約を無くした方が良い5つの理由 

1. ストーリーテリングとの相性の悪さ DDD の最も強力な要素の一つは、イベントストーミングなどのストーリーテリン グツールを通じて、技術者とドメインエキスパートの間の壁を取り払うこと しかし集約は、ストーリーから自然に浮かび上がる要素ではない 集約は一貫性を保証する境界であり、本質的に技術的な概念 ドメインエキスパートには理解しづらい 従来のモデリングファースト／データ中心のアプローチに逆戻りし、振る舞いか らモデルへと焦点を移してしまう 

2. 技術的側面とビジネス側面を混在させる 集約は以下の2つの異なるモデルを1つにまとめようとする i. 不変性を保証するためのモデル ii. ドメイン概念に関するメンタルモデル しかし、多くの場合この2つは一致しない 強い一貫性制約が常に同じビジネス概念内に存在するとは限らない、しばし ば2つ以上のビジネス概念の中間領域に存在する 集約モデリングの作業が、ドメインの実体である名前を探すだけに終わってしま うケースが多い 

3. 競合を増加させる 集約の責任、つまり境界線は往々にして拡大しやすい 新たなビジネス概念を既存の集約に割り当ててしまう傾向がある 集約の一貫性の境界は、同時実行性の境界でもある 例: コースの定員更新とコース名の変更という2つのコマンド これらの操作は論理的に競合しないが、同じ集約に属するため、順次実行さ れなければならない https://sara.event-thinking.io/2023/04/kill-aggregate-chapter-4-the-larger-the-aggregate-the-greater-the-contention.html 

4. リファクタリングを困難にする 集約をリファクタリングする場合、イベントストアを書き換える必要が生じる イベントソーシングにおいて、各ドメインイベントは一つの集約にのみ属する、 つまり集約・イベント・イベントストアの間に強い結合ができる イベントソーシングのイベントストアを書き換えるのは困難 (本来やるべきではない) 開発が進んだ後で、集約の設計のミスに気付くことがある ビジネス要件が時間の経過とともに変化し、それに応じて集約を修正する必 要が生じる可能性もある リファクタリングを諦めざるを得ない場合もある 

5. 複雑さを増加させる 集約の目的の一つは境界を定め、複雑さを抑制し、凝集性を高めること しかし、処理が複数の集約にまたがる場合、逆に複雑性が高まる ある集約の更新は成功しても別の集約の更新には失敗することがある 長いトランザクション、或いは前の処理を取り消す補償処理が必要になる https://sara.event-thinking.io/2023/04/kill-aggregate-chapter-6-the-aggregate-could-cause-unecessary-complexity.html 

集約を無くしたい理由 ストーリーテリングと相性が悪い 振る舞いではなくモデルに焦点を当てる 技術面とビジネス面を混在させる 不必要な競合を引き起こす可能性がある 不必要な複雑さを引き起こす可能性がある リファクタリングが難しい 

どうしたら集約なしで一貫性を保てるのか？ Dynamic Consistency Boundary (動的一貫性境界) 続きは次回の勉強会で！