メタボリック ドメイン

DCIの説明を受けた際に、関連して考えていた、DCIが嫌っている状況と考えられるものを不吉な臭いとして 言葉に記述しておく。

メタボリック ドメインの 症状

1つのEntityの中にたくさんのメソッドがある。そのメソッドがいつどこで（どのストーリーを実現させるために）必要とされているかが、すぐに判別できない。Entityの行数が長く、読む気になれない。複数人で複数のフィーチャの機能追加した際に、Entityやそのテストで、コンフリクトがよく発生する。

メタボリック ドメイン の　背景

ドメインモデル重視のアプローチは、
ドメイン貧血症（DDD）を避けるため、
トランザクションスクリプトによるスパゲティーコード化を避けるため、
MVCの中でController 側よりも、Model側に ロジックが書かれる事が好まれる。

発病

ところが、フィーチャを追加するたびに、だんだん Model が肥大化する。
1のEntityには、複数のStory 実現のための たくさんのmethodが混ざる。
結果、１つのエンティティのファイルサイズが肥大化する。
あるメソッドが どのユーザストーリーを実現するためののものなのかが
すぐに判別できず、Entity が ダーティ化する場合がある.。(かといって、コントローラ側に配置すると、トランザクションスクリプトの スパゲティコード化 に陥る。)

思考実験 例

下記のようなシステム構成のケースがあるとする。

注文受付のアプリケーション.war ---
請求書発行のアプリケーション.war ---|- コアモデル.jar <-> database
管理者向けのアプリケーション.war ---

注文受付のアプリケーションにしか関わらないストーリー実現のロジックを コアモデル に混ぜると、
請求書発行のアプリケーション、管理者向けのアプリケーションにはノイズになる。
今はアプリケーションが３つだが、６個になれば、ノイズの影響範囲はさらに広がる。

その他。DCIの目指すところ。

DCIの場合は、コアモデルには、各々のアプリケーション固有のロジックをそぎ落した dataがのこり
代わりに ユーザのメンタルモデル ＆ dataと紐付け をうまく考慮して Role側に behavior（ロジック.BDDの Bとの差異に注意）を配置、dataと roleを アプリケーションのcontext上で 紐付け interaction させる 、だろう。
DCI 理解度は、まだ今イチ（とくに intercactionが）。 全貌はつかめてない。