Model View ViewModel
UIを持つソフトウェアはしばしばドメインを司るエンジニアとUIを司るデザイナーの協業によって開発されるが、彼らが用いるツール・言語は必ずしも一致しない。MVVMが解決する課題の1つ目はこの不一致の許容である。
ドメインデータとUIすなわちModelとViewは、表示(model→view)と操作(view→model)の関係をもつ。シンプルなケースではmodelの状態がそのままviewに表示され、viewの操作がそのままmodelの状態変更に適用できる(データバインディング)。しかし現実にはviewとmodelは1対1対応しない。model内の複数の要素から算出される値がviewでの表示に相応しい場合や、viewの操作に基づいた演算結果をmodelに適用したい場合(viewではなく演算だがドメインロジックではないケース)が頻出する。結果として状態を持つmodelとは別に、view自体にも状態を持たせる必要が出てくる。MVVMが解決するもう1つの課題はこのviewが持つ状態の表現である。
Viewでも同様の問題が起きうる。Viewはコマンド発行演算のみをおこなうべきだが、コマンドの引数を計算する過程などでビジネスロジックを埋め込む実装ミスがしばしば発生する。
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き(ビジネスロジック - ショッピングの合計額や送料を計算するなど)を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み(データベースなど)が使われていたり、サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。MVVMの概念ではMVCの概念と同様に、データの(UI以外の)入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる。
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。