ビジネスモデルのシミュレート

業務アプリケーションの開発とは、ビジネスモデルをどのように実装するのかということだと思っています。ここでいってるビジネスモデルとは、実際におこなっている業務、あるいはこれからおこなおうとしている業務の形態・仕組みを指すこととします。
ということは、ビジネスモデルと実装のギャップが少なければ少ないほど、業務アプリケーションの開発は、スムーズに行われることになります。
くーすの基本的な考え方は、ビジネスモデルをシミュレートして設計・実装モデルを作ることです。余分なギャップをできるだけなくそうと考えています。
ビジネスモデルは、基本的に、イベント(本を発注するだとか)を起こすアクターとイベントを処理する受付係とイベントの内容を記述する伝票、何らかの情報をアクターにフィードバックする帳票から成り立っていると思います。
くーすで、これをシステム化する場合、伝票のレイアウトは画面、伝票のデータはDTOに一時的に格納されます。DTOの内容は、ER分析されてテーブルにマッピングされ、最終的には、テーブルに格納されます。受付係がおこなう業務手順は、手順ごとに業務ロジックコンポーネントにマッピングします。後は、データにアクセスする部分をDAOに切り出せばOK。ビジネスモデルをシミュレートしているので、設計・実装に特に悩む必要もありません。
ビジネスモデルに変更が入ったとしても設計・実装にきれにマッピングされているので、容易に変更することができます。
ドメインモデルの場合、伝票の内容を分析して、本来あるべきモデルを作成します。本来あるべきということは、非常にあいまいなものです。何度も同じようなドメインを分析して、共通的な部分が見つかったら、それは本来有るべき姿に近いといえるのかもしれません。
実際の開発では、同じようなドメインを何度もしかもモデラーとして担当することは、そうあることではありません。しかも、ビジネスの変化は早く、ドメインも変化しつづけます。過去のモデルは役には立っても、そのまま使えば良いということはめったにありません。
仮に、本来あるべきモデルの構造が作成できたとしましょう。今度は、受付係がおこなう業務手順をモデルにマッピングしていきます。この作業は、本来別々のものをがっちゃんこする作業なので、簡単な作業ではなく、人によってばらつきも出るでしょう。
仮に、業務手順をうまくマッピングできたとしましょう。ビジネスモデルに変更が入った場合に、ドメインモデルをきちんと変更するのは、そう容易なことではありません。なぜなら、ビジネスモデルとドメインモデルにはギャップがあるためです。
しかも、ドメインモデルは、プレゼンテーション層のモデルともリレーショナルモデルともギャップがあることがほとんどです。リレーショナルモデルとのギャップは、O/Rマッピングにより、一部解消できるとしても、プレゼンテーション層のモデルとのギャップは、ViewHelperパターンなどを使って、コードで埋めるしかありません。
ドメインモデルを成功させるためは、そのドメインに対する経験豊富なモデラーが必要です。初めてのドメインに対しては、ある程度の試行錯誤、場合によっては一部やり直す部分も出てくるでしょう。リスクと工数増加が懸念されます。
そうやって作り上げたドメインモデルは、ビジネスモデルの変更にそれほど強いわけではありません。変更された部分をかえるのはあたりまえのことですが、ビジネスモデルとのギャップがある分、変更が飛び火する可能性があります。ビジネスモデルをシミュレートしている場合は、対応がとれているので、変更の影響範囲は、ビジネスモデルと同等ですみます。
なおかつ、プレゼンテーション層のモデルとのギャップによって、工数が膨らみます。
ドメインモデルは、リスクがあり、工数がかかるというのが、私の考えです。


一部に誤解があるようなので、書いておきますが、私の書いていることに新しいことはありませんし、新しいことだと思っているわけでもありません。
ただ、業務アプリケーションを開発するときに、従来のドメインモデル型ではなぜだめなのか、それではどうすれば良いのかをわかりやすく伝えたいと思っているだけです。