なぜビジネスロジックが集まる層を「モデル（Model）」というのでしょうか？

Question

MVCなどの概念でビジネスロジックを担当する層として「Model」という層が登場しますが、なぜこの名前なのでしょうか？

個人的な印象ですがモデルは「模型」のようなニュアンスが強いと思っていて、名前だけ聞くとデータオブジェクトのような雰囲気があります

MVVMの「ViewModel」はまさにモデルっていう感じで納得できるのですが、今まで見てきたMVCやMVVMのModelはビジネスロジックを担当していたりデータストアとのやりとりを担当していることが多いように感じました

また解説書や解説サイトなどでもModelはビジネスロジックを担当する層という説明がよくでてきます

アーキテクチャ自体に疑問はないのですがなぜこの層をModelというのでしょうか？
由来をご存知の方いたら教えて下さい

Comments

[unoSSkR]

Thanks to Smalltalk-80 and its developers. Simply a Model means a modelled thing, so the answer by Mr ozwk is surely the best among the other answered!

Answer 1

モデルという語の由来

英語の辞書を調べましたがこれというものがありません。そこで、他の回答者の意見も参考にして考案しました。モデルとは、物理学、工学、経済学などの分野で、その分野に固有の言語を使って表現した『対象の本質的な振舞い』と定義します。

初期のMVC

MVCの初期の論文に解説があります。MVC XEROX PARC 1978-79

controller (input) 入力（ボタンなどの入力用部品）
view (output) 出力（表示のための出力用部品）
model (mental model) ユーザーが心に描くアプリケーション機能

controllerとviewは一体となってToolと表記されていますが、今の言葉で言い直すとGUIです。画面(GUI)の背後にあって、ユーザーが心に思い描く像がモデルです。モデルとは問題領域の本質的な振る舞いを表す。おっしゃるとおり、ビジネスの領域では、ビジネスロジックの集合がモデルと考えられます。

ここから『GUIを取り去っても、付け加えても、アプリケーションの本質的な機能は変わらない』というモデルの要請が生まれます。

MVCとレイヤーアーキテクチャ

MVCアーキテクチャとレイヤーアーキテクチャとの類似点を見てみましょう。

• プレゼンテーション層 GUI(View、Controller)
• ビジネスロジック層 対象領域の本質的な振舞い (Model)
• 永続化層 Modelを格納するストレージ

レイヤーアーキテクチャは上位層から下位層の呼び出し方法が決まっている。層が独立していて取り替えや並存が可能。プレゼンテーション層は、HTTPプロトコルだけでなく、別のUI機能を付け加えたり削除できます（複数のGUIが併存してもよい）。永続化層もRDBだけとは限らず多くのストレージが並存可能。アプリケーションの本質であるビジネスロジック層はモデルを表し、GUIにもストレージにも依存しない。別のプラットフォームにマイグレーションすらできるのが理想だと考えます。

Comments

[jimyo]

> ここから『GUIを取り去っても、付け加えても、アプリケーションの本質的な機能は変わらない』というモデルの要請が生まれます。

Chironian さんの回答と重なる部分があり腹落ちしました

一次ソースまで紹介していただきありがとうございました

[xebme]

英語の綴り間違いを訂正しました。

Answer 2

科学分野で、ある物事を考えるときに、その物事を単純化したり抽象化したりして
取り扱いやすくすることを「モデリング」と呼んで、その成果物を「モデル」と呼びます。

Answer 3

ASP.NET MVC の場合で、他は違うかもしれませんが・・・

MVCなどの概念でビジネスロジックを担当する層として「Model」という層が登場しますが、なぜこの名前なのでしょうか？

ASP.NET MVC の場合は以下の画像のような構造で 3 種類の Model が存在します。「ビジネスロジックを担当する層」＝「Model」という訳ではなく、下の画像で言うと「ドメインモデル」にビジネスロジックが含まれる場合があるということになります。

なので、

ビジネスロジックを担当していたりデータストアとのやりとりを担当していることが多いように感じました

は ASP.NET MVC の場合はその通りで、上の図の「入力モデル」をクライアントから送信されたデータを Controller で受け取るのに利用、「ビューモデル」を Controller から View にデータを渡すのに利用、「ドメインモデル」は「中間層（例えば Linq to Entities でその先が DB）」とのデータのやり取りに利用すると言った感じです。

ただし、図にあるように各 Model 間で重なっている部分があります・・・と言うより、Visual Studio で生成する Entity Data Model のように 3 つの機能がその中に入っていることもあります。

Answer 4

こんにちは。

ビジネス・ロジック部分は、実世界の作業を仮想化したものだからだと思います。
例えば、発注→納品→精算の各実世界における作業に対応してビジネス・ロジックは構築されます。つまり、リアル世界のモデルとなっている筈です。
逆に現実世界からかけ離れたビジネス・ロジック部を持つプログラムは実世界の作業の変化に追従して改造することが非常に困難でしょう。そのようなプログラムは役に立ちません。

Comments

[jimyo]

> ビジネス・ロジック部分は、実世界の作業を仮想化したものだからだと思います。
例えば、発注→納品→精算の各実世界における作業に対応してビジネス・ロジックは構築されます。つまり、リアル世界のモデルとなっている筈です。

これ非常に分かりやすいです
ありがとうございます

Answer 5

モデル

「概念」のところを見ると、モデルという言葉であっても特におかしくないように思います。

追記

オブジェクト指向 - 「モデリング」とは要は「視覚化」すること?｜teratail

Answer 6

MVVMでは、役割がはっきりしているView、ViewModelと違ってModelについては細かく定義をしてません。
ViewとViewModel以外はすべてModelです。
Modelは複数の層を持ったりして構造化されているのが普通ですから、
そういった漠然とした構造→Modelととらえてもいいんじゃないでしょうか