Model

元は建築や機械、物理、化学分野で使われがちな言葉だったのでは・・？

1960年代後半のソフトウェア危機において、ソフトウェア工学の必要性が認識された。

従来のソフトウェア開発は職人芸

ソフトウェア規模の拡大により（OS/360) 、体系的な開発手法、品質管理が必須と考えられるようになった。

1970年代に、計算機システムのための著名なモデリング技法がいくつも登場している。

DFD（Data-flow diagram）：システムのプロセスの図的表現。プロセスモデリング。

関係モデル：データモデリング。

ER図：概念データモデリングの手法として。三層スキーマにおける概念スキーマの設計。

View：外部スキーマ。１つの概念スキーマに対して、多様なユーザー要求の観点での見え方を与える。

1980年代　GUIを持つアプリの登場とともに、データベースから離れた場所で Model という言葉が注目された。

MVC (Model-View-Controller)

最初のGUI環境Smalltalk-80の実装を中心に、オブジェクト指向、そしてMVCが登場する。

MVCの最初のアイデアはTrygve Reenskaugによる。

造船所の開発プロセスの図的表現による管理を目的とした計算機システムの設計例。

Thing

もの、こと

Model

１つのThingを何らかの観点で抽象化したもの。複数の小さなサブモデルの集合であることも。

Modelは抽象データ型（データとそのデータに対する操作の組）で表現。

View

１つのModelは複数のViewを持ちうる。表示項目の異なるリスト、ダイアグラム。

関係モデルにおけるViewとは異なり、GUIにおける視覚的なViewが検討される。

Trygveはユーザのmental-modelにも触れているが、その後のMVCの議論でユーザのmental-modelの観点でMVCを論じたものは見たことがない。

Modeling（設計）、xxx Model（関係モデル等）という形ではなくダイアグラム上のノードとして「Model」という言葉が現れる、つまりシステムの1要素としての「Model」が認識されるのはMVC以降ではないか？

Modelという言葉には、そこに関わるもの・こと全てを包括した１つの世界観を描くものという印象があるが、ここではやや違うのではないか？

ここでは、Modelには必ず「外側」（View、Controller）が存在し、それらの統合によって1つのGUIアプリ、つまり、人間を巻き込んだより大きなモデル（システム）になるという階層構造を前提とした世界観がある。

MVCの広まり

Modelが何を指すのか？何が含まれるのか？はアプリによる。

当時のGUIアプリの規模を思えば、とても小さいということも普通にある。

小さなデータを1つ持つ程度かもしれないし、複雑な構造を持つかもしれない。

こちらで書かれていることは妥当に思える。

"A Cookbook for Using Model-View-Controller User Interface Paradigm in Smalltalk-80"

The model of an application is the domain-specific software simulation or implementation of the application's central structure. This can be as simple as an integer (as the model of a counter) or string (as the model of a text editor)

今でもモデリングにおいて広く使用される Domain という言葉は、当時から既に見ることができる。

たぶんもっと遡れると思うが。

その後のSmalltalk実装であるVisualWorks 2.5のチュートリアル（1995年）を読むと、Domain ModelsとApplication Modelsを区別するという、後のMVP、MVVMで顕著になる観点がすでに存在している。

Domain Models

アプリが自動化を支援する業務領域において、現実のオブジェクトの状態と動作をシミュレートする。

Application Models

GUIの個々の部品に固有の動作を定義する。

オブジェクト指向モデリングの流行 1980年代～

BCEパターン

Boundary - Control - Entity

EntityはMVCにおけるModelに相当

UMLの登場

Domain-Driven Design　2003年～

ドメイン分析において、ドメインエキスパートと開発者が共有する共通言語（ユビキタス言語）を定めることによって、分析を進める。

問題領域を語彙のレベルで定義しなおすことが重要となる。

問題領域ごとに領域の専門家と開発者の間にcommon groundを作ってゆく、その過程かつ結果としての共通言語。

Modelが何を指すのか？何が含まれるのか？はアプリによる、ということを開発現場で突き詰めるとこういう考えに至るのだと思う。