業務ルールをドメイン層へ集めようとすると、判断に必要な外部情報を取得する責任までモデルへ取り込みたくなる。しかし、ルールの集中と外部通信からの分離は、別々に評価する必要がある。
Vladimir Khorikov は、全業務ルールがドメイン層にあることを完全性、モデルがデータベースなどのプロセス外の依存先へアクセスしないことを純粋性と呼ぶ。ここでの純粋性は外部通信の有無を指し、エンティティ自身の状態更新まで禁止する定義ではない。
メールアドレスの重複確認が例になる。コントローラーで確認すればルールが分散し、モデルから問い合わせれば純粋性を失う。全利用者を先に取得してモデルで判定すれば両方を保てるが、取得量が増える。リポジトリをインターフェースにしても、呼び出しが外部通信を起こすなら純粋性は戻らない。
著者は、性能を損なわずに取得、判断、保存を分けられるならその構成を選び、難しければ完全性より純粋性を優先する。複雑な業務判断に外部通信の責任を重ねるより、一部の判断が外側に残るほうが扱いやすいという選択である。
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/
この選択は、副作用を境界へ集める設計が、必要な情報を安価に事前取得できない場面でどこまで成り立つかという問題でもある。
自分の整理では、判断結果を決めるルールの集中と、判断材料の取得を含む自己完結性を区別したい。重複の有無を値で渡し、拒否の判断をモデルに置くことはできるが、その値が正しく取得されたかまでモデル単独では保証できない。参照透過性と自己完結性を分けて考えると、何を外側へ委ねたかが明確になる。判断途中の追加取得が必要なら、中断を値として表す方法も比較対象になる。
#domain-model #domain-driven-design #software-design #side-effect