モデル：2つの非常に異なる概念
モデルとは何かについて、多くの質問と回答があります。特に、ビジネスロジックが属する場所とMVCパターンについて説明する場合。切断する必要がある2つの概念があるようです。この具体的な説明に対する質問に価値があると思います。
オプションは次のとおりです。
- シンプルなデータキャリア。いくつかの基本的な検証を除いて、何も考えていません。 （例：POJO/POCO、ビューモデル、データベーステーブルにマップされたクラス）（例 ここ および ここ ）。
- すべてのビジネスロジックとデータアクセスを含むレイヤー全体（またはレイヤーのグループ）（例： here 、 here および here ）。モデルほとんど anything ）にすることができます。
モデルという用語は回復を超えて苦しんでいるようです。人々は アーキテクチャを変更する という用語があいまいであることを認識せずにいます。
おそらく、このあいまいさの完璧な例は、MicrosoftのMVCのアーキテクチャ図です。MVCパターンは明らかにUIレイヤーにありますが、モデルの概念は明らかにすべてのレイヤーに及びます。
これは、初心者と経験豊富なソフトウェアエンジニアの両方にとって非常に 混乱 です。
オプション2はとにかくが definitions Wordモデルの 。それは役に立ちません。
私の質問は：
- 重要なものを見逃したことはありますか、それともモデルに何が起こったかを正確に説明していますか？
- option 2は直感的ではないので、これらの異なるレイヤー（サービス、リポジトリなど）に適した単語がないか）を検討してください。
これらのディスカッションの1つの問題は、同じディスカッションまたはダイアグラムで異なるアーキテクチャの視点がすべてから頻繁に混在することです。
- 一部のアーキテクチャの視点は、深さを示すことを目的としています。特定の機能がどのように実装されているかを深く掘り下げます。
- 一方、他のアーキテクチャの視点は、幅を示すことを目的としています：ピアであるコンポーネント（深さに関して同じレベルに存在する）の相互作用。
同じダイアグラムで両方の視点（深さと幅）を混在させると、混乱が生じる傾向があります。あなたが引用している情報源を調査したところ、これらの種類の混合が理想的であり、建築的視点を分離することに何の不足もありません。
たとえば、表示している図（Microsoftを引用）は、MSがMVC図であると主張していますが、主にドメインモデルの深さを示しており、（MVCの観点から）持続性に重点を置いています。したがって、この図は、相互作用するピア（M、V、C）の幅広い視点に弱く、いくつかの深さの視点と永続性が混在しています：ブレークアウト（および他のコンポーネントのピアになるために昇格）。ドメインロジックがどこに属しているのか、アーキテクチャの観点から考えると、すべてのものが簡単に混在できるのではないかと疑問に思われるかもしれません。
MVCでは、モデルはドメインオブジェクトの維持、ドメイン指向のクエリとコマンド（検証などを含む）への応答、ドメイン指向のルールと動作の適用/実行を担当します。 MVCは永続性の破壊については触れていません。システムに永続化が含まれている場合、それは実装の詳細（幅ではなく深さの詳細）です。したがって、ドメインロジックがMVCのどこに属するのか、またはドメインオブジェクトが無意味なのかスマートなのかは問題ではありません。これらの問題はすべてモデルの内部的な側面（実装の詳細）です。
また、モデルという用語が過負荷になり、過剰に使用されていることも正しいことです。したがって、この用語の意味するところは、いくつかの状況で評価する必要があります。残念ながら、これらの議論の多くはコンテキストを設定または維持できず、混乱を招いています。
MVCでは、モデルという用語は、私が前述したもの（ドメインオブジェクトのキーパー、クエリとコマンドのハンドラーなど）を意味します。 POJOについて話すかもしれませんが、そのような議論は、ピアM、V、C間の相互作用、およびモデルへのクエリとコマンドのインターフェイスがdumberオブジェクトまたはよりスマートなオブジェクトを使用するかどうかに適用されます。
永続化の詳細（MVCの観点からの実装の詳細）では、永続化メカニズムのさまざまな場所でPOJOやスマート/ダムに話しかけることができます。永続化の実装の詳細では、さまざまなインターフェイスで用語モデルを再利用することもできます。
要約すると、モデルという用語は、あなたが説明している両方の方法で使用される可能性があります—それはどちらか一方ではありません。混乱を招くのは、多くの場合、コンテキストの設定に失敗したり、コンテキストを幅（ピアコンポーネントの相互作用）から深さ（通常、これらのコンポーネントの1つの実装の詳細）にシフトしたときに表示に失敗したりすることです。
MVCでは、モデルはビューまたはコントローラーの一部ではないものです。 MVVMでは、モデルはビューまたはViewModelの一部ではないものです。覚えやすいでしょう。
その定義で満足できない場合は、モデルを問題のドメインに直接関連するすべてのコンポーネントとして考えてください（CustomerクラスやInvoiceクラスなど）。それ以外はすべて、UI抽象化の一部です。UIはすべてMVCとMVVMです。
言い換えれば、MVCとMVVMは、実際にはモデルについては何も言わないアーキテクチャの観点からです。モデルの構造と構成は完全にあなた次第です。 MVCとMVVMは互いに関係しています主に他のコンポーネント（ビュー、ビューモデル、コントローラー）。
さらに読む
ウィキペディアのドメインモデル
モデルは「その他すべて」ではありません。モデルは3.14159の後ろの数字です・・・「3.14159265」ではありません。円周率を取得するために押すボタンではありません。 πを書いた紙ではありません。円周と直径の比率を伝えるために使用する点滅ライトではありません。波、タイヤのローリング、回転したテキストなど、他の楽しいものを計算するときに使用する数ですが、モデルを選択します。
さて、確かに half ta は、ライブラリから引き出すことができるばかげた定数ですが、重要なのは、モデリングのニーズに基づいてモデル化する方法を決定する必要があるということです。これは、アプリケーションが世界をどう思うかです。それがモデルです。モデリング以外の方法、表示、操作、記憶、通信などは、モデルの仕事ではありません。
モデルにビジネスルールを入れることができます。しかし、それらのルールは何かをモデル化することに関するものである方がよいでしょう。他には何もありません。
これらのルールに従うことは、何かをうまく配置できる場所がないことを意味します。それを維持するためにどこか新しい場所にしてください。パッケージ化されたデザインを盲目的にフォローすると、あなたの問題があなたに必要なことを伝えていることに注意を払うのであれば、あなたは不敬な混乱を起こすでしょう。
モデルという用語を明確にするために、1979年に書かれたMVCコンセプトに関するTrygve Reenskaugのオリジナルノートの定義から始めましょう。
モデルは、コンピューティングシステム内のデータの形で抽象化をアクティブに表現したものです。
Thing-Model-View-Editorモデルは知識を表します。モデルは単一のオブジェクト（興味深いものではない）でも、オブジェクトの何らかの構造でもかまいません。
モデル-ビュー-コントローラ
最初の論文のモデルの定義に続くコメントで、Reenskaugはモデルをコンピューターでどのように表現すべきかについての概要を説明しています。
モデルは、これらのデータを処理するために必要なメソッドとともにデータのコレクションとして表されます。
理想的には、すべてのモデルは完全に一貫している必要があります。
Thing-Model-View-Editor
Reenskaugは、1つの単語で2つの概念を定義しているようです。モデルは、コンピューターで表現される抽象であり、抽象の表現でもあります。これらを区別する必要があります。抽象化としてのモデルと、その抽象化の表現としてのモデルです。
別の記述は、新しいSmalltalk-80プログラマーに不可欠な情報を提供する彼の論文でスティーブバーベックによって提供されています。
[T]モデルはアプリケーションドメインの動作とデータを管理します
Model-View-Controllerの使用方法
また、モデルをアクティブな表現と見なします。
1980年にテッドコッドの論文が最初に発行されました。その中でデータモデルは次のように定義されています...
... 3つのコンポーネントの組み合わせ：
- データ構造タイプのコレクション（モデルに準拠するデータベースのビルディングブロック）;
- 演算子または推論規則のコレクション。これは、（1）にリストされているデータ型の有効なインスタンスに適用でき、必要な組み合わせでこれらの構造の任意の部分からデータを取得または派生できます。
- 一貫性のあるデータベースの状態のセットまたは状態の変化、あるいはその両方を暗黙的または明示的に定義する、一般的な整合性ルールのコレクション。
Chris Dateもデータモデルを次のように定義しています...
...オブジェクト、演算子などの抽象的な自己完結型の論理的な定義であり、これらが一緒になってユーザーが対話する抽象的なマシンを構成します。オブジェクトを使用すると、データの構造をモデル化できます。演算子を使用すると、その動作をモデル化できます。
データベースシステムの概要（第8版）
これらの定義では、データモデルは正式な抽象概念です。これらのReenskaug状態と一致するコンポーネントは、コンピューターで表現されるモデルを構成する必要があります。したがって、抽象化としてのモデルはデータモデルであると結論付けられます。
DBMSはデータモデルを実装します。ユーザーはオブジェクト型の構造を作成できます。事前定義された演算子のコレクションを作成または使用して、そのデータを処理します。データの整合性を確保するために、制約を宣言および/または実装します。したがって、抽象化の表現としてのモデル、つまりMVCフレームワークのモデルコンポーネントは、DBMSであると結論付けられます。
あなたの質問まで：
モデルで提供されている両方の概念で何かが欠けているように思います。
場合によっては、これらの他の名前は必ずしもモデルと同じレベルであるとは限りませんが、モデルの一部になることがあります。
見た目の違いがまったく起こらない場合があるというわけではありません。
ある種のモデルにアプローチするとき、私はいくつかのことを遠近法で捉えようとしています。
モデル自体から：
私（モデル）は自分について何を知っているべきですか？
- もののリストを作成する場合、自分の位置を知っている必要があるか、公開された値を定義するために使用されるアイテム/式/制約を知っている必要があるかなど
モデルを呼び出すものから：
式/制約の結果をモデルに提供しますか、それとも結果の決定方法にとらわれないのですか？
- モデルが解析/決定する必要のない値または派生ルールを決定するための位置（x＆y、またはコンテナのグループ）のようなもの
したがって、ビジネスロジックの異なる部分が属していない場所にある場合がありますが、それは実際には、時間の経過とともに変化する可能性がある一部のアプリまたはドメインの全体的な意図に依存します。
より適切な名前の概念については、サービスやリポジトリなどが必ずしも同じレベルにないかどうかを述べる理由は、上記と同じ理由によるものです。
- サービスとして、私の結果はモデルとして使用されていたものですか、それともモデルに関連付けられた他の値を導出するために使用されていますか？
一歩戻りましょう。
他のすべての注意をそらすWordの定義に関係なく、テクノロジーにおけるモデルは、問題についての実行可能な画像であり、アナロジーであり、創造物についてのコミュニケーションを可能にするものです。同じものがすべて理にかなっている多くのモデルがあるかもしれません。また、1つのモデルが複数の目的で機能する場合もあります。茎と枝のある木のように、多くの技術的な要素で機能するモデルです。
ソフトウェアモデリングでは、モデルはほとんどの場合、システムの一部未指定です。アプリケーションごとに異なるため、不定です。したがって、混乱を招きます。あなたはあなたのデータベースを持っています（かなり具体的で、誰も持っていませんか？）、あなたはあなたのUIを持っています（申し分なく、私はそれが何であるかを知っています）、そしてあなたはあなたが定義し、解決するまで次第に何かを持っていますアプリケーションのコアであり、同じ設計原則に従う他のアプリケーションとは異なります。それが「モデル」になります。