MVCに関するドメイン、モデル、およびエンティティの区別
誰かがこれらの3つの概念と、MVCフレームワークに関してそれらの違いを例とともに説明できますか。私にはこれらはほとんど同等に見え、一部の記事では同じ意味で使用され、他の記事では使用されていないようです。
用語は私が同意する少しあいまいです。私はdomainを使用して、あなたが扱っているビジネスエリアを参照します。銀行や保険のようなもの。次に、ドメインモデルがあります。これらは、そのビジネスドメインで扱うものです。たとえば、アカウント、顧客、振替などがある銀行のdomainなどです。用語エンティティを使用しますクラス/ POJOまたは永続的/具象バージョンのモデルを参照するため。
おそらくあなたを混乱させるのは、用語[〜＃〜] mvc [〜＃〜]では、modelは具体的なことですが、Web GUIでのプレゼンテーションを表すために使用されるデータモデルを参照するため、上記の説明と混同しないでください。
混乱する用語は、「 ドメインオブジェクト 」、「ドメインエンティティ」、および「モデルオブジェクト」です。通常は交換可能に使用されますが、ドメインエンティティとモデルオブジェクトは アクティブレコード パターンのインスタンスにすることもできます（基本的には、ストレージロジックが追加されたドメインオブジェクト）。
通常のドメインオブジェクトには、ストレージロジックはありません。 data mappers で処理されます。
「モデルオブジェクト」という用語は、ファウラーの書籍に由来します（詳細については PoEAA を参照してください）。また、IMHOは混乱MVCの一部です。プレゼンテーション層）。これらの「モデルオブジェクト」を含み、通常は services で処理されます（この画像では、モデル層は3つの同心円すべてです）。
代わりに「ドメインオブジェクト」という用語を使用することを好みます。
「ドメインエンティティ」（または「エンティティオブジェクト」）という用語は、通常、作成者がオブジェクトがストレージ構造の直接的な表現であることを示す場合に使用されます（多くの場合、データベーステーブル）。これらはほとんどの場合、アクティブレコードの実装でもあります。
P.S.:一部の記事では、用語「モデル」（複数）も表示されます。通常、MVCデザインパターンには直接関係しません。「モデル」が単なるアクティブレコードであり、コントローラーに直接公開/作成されるRailsのようなアーキテクチャについて説明しているためです。
..これがあなたをもっと混乱させたかどうかわからない
記録のために。実際には、ドメインとモデルは同じですが、エンティティはデータベースに格納するために使用されるドメイン/オブジェクトでもあります。
一部の人々はそのようなトピックを再説明しようとしますが、それらのどれもキヤノンではありません。
違いは、Javaの世界ではDomainがより多く使用されるのに対し、C＃の世界ではModelが使用される（そしてMSが使用を推奨する）が、その単なる慣習であり、両方を使用できることです。
同じ概念で、Javaの人々はValue Object（VO）を使用しますが、C＃の人々のDTOは両方とも実質的に同じ場合でも使用されます。 POJO（Java）vs POCO（C＃）、Packages（Java）vs NameSpace（C＃）、Setter and Getter（Java）vs Encapsulation（C＃）
ドメインとモデルは両方ともクラスです。クラスがどのように使用されるかによって、クラスを分類してドメインまたはモデルフォルダーに配置する必要があるかどうかが区別されます。クラスがビューでのみ使用される場合は、モデルフォルダーに配置します。クラスがデータベースオブジェクトにマップされている場合は、ドメインフォルダーに配置します。
ドメインは、データベーステーブル、外部サービスオブジェクトなどのクラスであると言えます。したがって、プロジェクトを開発してディレクトリドメインを作成する場合、データベースオブジェクトをその中に配置します。そのようなクラスはエンティティであり、そのプロパティを持つCustomerクラスになることができます。なぜそれがエンティティであり、POCOではないのですか？それはその使用法のためです。エンティティのコンテンツは、データベースに対して読み書きできます。エンティティとして考えているため、どこで使用できるかがわかります。あなたがそのエンティティを知っているという知識によって、あなたはそれをその名前に入れない。さて、モデルについて。この顧客を使用している場合、使用したくないプロパティが存在する可能性があります。顧客は本当にシンプルなエンティティになります。しかし、複雑なものがあるとしましょう。使用しないプロパティが非常に多いWebサービスから読み取るもの。次に、このエンティティを読み取り（=シリアル化で完全に実行できます）、このエンティティを使用してそのエンティティを作成できます。そのエンティティがデータをモデルにコピーするために使用される場合、データ変換オブジェクト（DTO）についても話します。これをCustomerDTOと書くこともあります。エンティティからモデルにデータをコピーするには、マッピングツールを使用できます。エンティティの名前はCustomerModelに変わります。次に、拡張モデルを使用します。そうしないと、何が何なのかわからなくなるからです。このCustomerModelには、他にも多くのプロパティがあります。これらのプロパティの一部は、プロセスプロパティにすることができます（Customerエンティティから取得する必要はありません）。これらのプロパティのコンテンツは、他のサービスから取得されます。 Customerから作成できる簡単なものはFullnameで、Customerのいくつかのプロパティから構成されます。そのため、CustomerModelの入力は複雑になる場合があります。 CustomerModelを埋めるためのコードをいわゆるFactoryに入れ、このCustomerFactoryを呼び出すことができます。