はじめに
この記事はZOZO アドベントカレンダー２０２２#５ 4日目の記事になります。
今回はドメイン駆動設計における集約に関する問題を考察してみます。
問題
システムの稼働が長くなればなるほど、新しい機能やサービスによって集約が大きくなっていって、いつのまにか保守性が下がるという問題があります。
いかに集約を小さくするかという問題を考えてみます。
作戦１ コマンドとクエリでモデルを分ける。
そもそもコマンド（更新や削除）とクエリ（検索）では、基本的な要件が異なるので、思い切ってモデルを分けるという考えになります。
アーキテクチャ的には多少複雑になりますが、クエリに必要なパラメータとか、レスポンスの値とかをコマンド側では考えなくて良くなり、コマンド用のモデルはシンプルになります。
一方のクエリは検索して結果を返すだけなことが多いので、そもそもしっかりモデルを考える必要がないこともあります。
作戦２ 集約をコンテキスト境界や担当業務ごとに分ける
コンテキストを意識して分けるやり方です。コンテキスト境界を意識して分けていく感じです。
いわゆるマイクロサービスの概念です。今回は詳細まで記載しませんが、アーキテクチャの実装については、モノリスのままモジュラーモノリスの形態を取るか、きっちりマイクロサービスのアーキテクチャを取り入れるか、いずれにしてもサービス間、コンテキスト間のやり取りをどうするかというところが難しいところですね。
まとめ
集約を小さく保つ、つまりコードをシンプルに保とうとすれば、するほどアーキテクチャは複雑になる傾向にあります。
もちろん集約内のドメインをいかに保守性高く保つかにも気を配らなければ元も子もないですよね。
アプリケーションの公開当初はシンプルであったとしても時間の経過につれて複雑になっていくものなので、いつどのようにアーキテクチャを変更するか、または最初から見越してやっておくかというのも決断が難しいところです。