ビジネスルールが表現可能なモデル

DDD

僕たちのチームでは、モデルは「概念モデル」・「分析モデル」・「設計モデル（ドメインモデル）」の３つのレベルで考える。このモデルを簡単に紹介すると。

  • 概念モデルはビジネス上ユーザが利用している識別子から導出されるエンティティのみで表現されるトップレベルのモデルである。概念モデルは以後の分析作業のベースになる。
  • 分析モデルは、ビジネス構造・状態のバリエーション、内部エンティティやビジネスルールを分析した結果を反映していくモデルである。
  • 設計モデルは、分析モデルをユースケースなどの観点から関心事ごとに取り出し、ドメインモデルとして実装するモデルである。

この中のモデリングの中心になるのが分析モデルである。分析モデルはビジネスの構造やビジネスルール・ポリシーなどを取り扱い整理することが目的になる。、ようはビジネス用語やルールが定義可能なモデルということである。
このため、分析モデルの表現力としては振る舞いや状態を取り扱うことができる必要が出てくる。ERでも導出項目を利用することである程度表現することも可能であるが、携帯電話の料金計算など非常に複雑な計算ロジックを表現することは現状難しいと考えている。クラス図であればビジネスルールのクラスやポリシークラスなどを導入することで簡単に表現することが可能である。

もちろん、このモデルを作成することは若干タフな部分もあるのは事実である。しかし、よりリッチな分析モデルを作成することでビジネスルールの共通化や安定化が進むことになり設計・実装でもそのメリットを受けることができる。
この作業を怠たり貧弱な分析モデルを作成した場合、共通化されないコードが増えたり、変更に敏感なコードができてしまう。この兆候は画面側にビジネスロジック的なコードが現れ、画面処理に多くのコードが書かれているかどうかで判断できる。このような場合、画面で表示している導出項目を分析モデルで表現し共通化できる可能性が高い。

若干タフではあるが意味論を利用してよりリッチなモデルを作成する動機はここにある。