MVCモデルのバリエーション

「ドメイン駆動設計はMVCモデルの後継者である」という指摘を見つけた時に、MVCモデルに幾つかのバリエーションがあるのに気づいた。
ファウラーのUIパターンが参考になる。
まとまりがないラフなメモ書き。

【元ネタ】
開発者が知っておくべき、6つのUIアーキテクチャ・パターン － ＠IT

matarillo.com: UIパターン

MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？ － ＠IT

お世話になります。 MVCとMVC2の違いについて、質問させてください。 - Yahoo!知恵袋

- デザインパターンによる進化的設計

Interactive Application Architecture Patterns

エリック・エヴァンスのドメイン駆動設計に沿ってSymfony2でユーザー管理アプリを作ってみたsoichiro.org ブログ | soichiro.org ブログ

分散オブジェクト・アーキテクチャ／ドメイン指向アーキテクチャ - Memorandum by zerobase

【1】Smalltalkの古典的なMVCモデルでは、UI＝ビュー、ドメイン(データとその振る舞い)＝Modelに相当する。
Controllerは、パソコンなどからの入力に相当する。
Modelが更新されるたびに、画面のUI情報が即座に変わって表示される。
MVCモデルの基本は、ModelとViewの厳格な区別。
いわゆるObserverパターンがその根底にある。

matarillo.com: UIパターンによれば「Fowlerの説明では、GUIコントロールはビューとコントローラーがペアになっているらしい。」
だからこそ、Observerパターンで、モデルが更新されるとビューも更新される。

しかし、MVCモデルの問題点は、Modelの状態の保持や、UIの状態の保持をどの層で実装すべきか、にある。
そして、そこから派生した問題として、ビジネスロジックを実現するオブジェクトとデータ永続層の間で、ORマッピングのインピーダンス・ミスマッチが発生する点がある。
この問題が根底にあると分かれば、その後の流れの理解はさほど難しくない。

【2】J2EEのようなWebアプリの設計では、MVC2モデルがある。
MVC2モデルでは、View＝JSP、Controller＝リクエストの入出力処理、Model＝業務ロジック＋永続層になる。
普通は、Modelがドメイン駆動でなく、ListやMapを駆使した手続き型ロジックになりがち。
ORマッピングはJavaなら、かなりたくさんの種類があった。

RailsのようなフルスタックのWebフレームワークでは、ActiveRecordがORマッピングを吸収し、インピーダンスミスマッチをほぼ解決した。
但し、ビジネスロジックをどこにおくべきか、については、まだ論争があるようだ。

しかし、ドメイン駆動設計の4層アーキテクチャならば、下記のように整理されるので、MVC2モデルでもドメイン層が明確になる。

・ユーザーインターフェース層＝Webシステムで言うView
・アプリケーション層＝Webシステムで言うController
・ドメイン層: すべてのビジネスロジックを集約した実装
・インフラストラクチャ層＝Webシステムで言うModel

【3】MVCモデルの問題点を解決するには、いくつかの方法がある。
以下、matarillo.com: UIパターンや開発者が知っておくべき、6つのUIアーキテクチャ・パターン － ＠IT参照。

プレゼンテーションモデルは「ドメインロジックだけを含むモデルをラップし、プレゼンテーションロジックを含むようなモデル（＝プレゼンテーションモデル）を用意すると言うもの。」
ドメインに関係する属性や振る舞いは通常のモデルに委譲する。
プレゼンテーションに関係する属性や振る舞いはプレゼンテーションモデルが担当する。
モデル側を改良したシンプルなパターン。

アプリケーションモデルは、プレゼンテーション関連のロジックは具象アプリケーションモデルに置き、アスペクトアダプターが具象アプリケーションモデルとモデルとのバインドを担当する。
最近のマイクロソフト界隈では、アプリケーションモデルの派生パターンであるモデル・ビュー・ビューモデル（MVVM）というUIパターンが語られているらしい。

モデル・ビュー・プレゼンター (MVP)は、コントローラの代わりにプレゼンターを導入し、プレゼンターがユーザー入力をモデルに伝える役割だけでなく、ビューを直接更新する役割を担う。
「ビューがモデルを監視するものを「監視コントローラ」、ビューがモデルを監視しないものを「パッシブ・ビュー」と呼んで区別することもある。」

これらのUIパターンを見ると、色んなモデルを用意して、それぞれの状況(文脈)に応じてMVCモデルの問題点を解決しようとしているのが分かる。

【4】これらUIパターンを整理したファウラーは、モデラーというよりも科学者のように思える。
その理由は、新しい概念を提唱するというよりも、コミュティやIT業界で知られているバラバラな経験や知識を整理して、それにネーミングして、新しいアイデアとして売り出しているからだ。

例えば、古くは「リファクタリング」「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」、最近なら「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」「ドメイン特化言語」の本を思い出す。
これらの本は、一つの辞書のように使えて、その中でネーミングされたパターンを他の人に話せば、コミュニケーションが成り立ち、議論が進む。
例えば、「知識操作パターン」「勘定パターン」「ActiveRecord」「トランザクションスクリプト」などのパターンがあるだろう。

ファウラーは、既にある程度知られているノウハウや知識を、パターンという形式を用いて理論化して体系化するのが上手いように思える。