实体与模型与视图模型

术语"；型号"；不明确。他们都是模特。

实体模型

在持久性方面与结构非常相似的类。MemberEntity是表示数据库中Members表中一个成员行的模型。不是严格绑定到数据库，而是某种持久性的实体。通常具有一个"；ID"；诸如"；int MemberID"；。

ViewModel

与View/UI上的结构非常相似的类。MemberViewModel是一个模型，表示要在应用程序前端的Members View/UI上显示的一个成员。与MV*模式没有严格联系。

通知

以上两个模型表示应用程序边界上的通信。即接收通信（用户事件和通过协议的通信）以启动业务规则的前端边界（入口点）；以及从业务规则中获取命令以打开与其他系统（如数据库或其他端点）的通信的后边界。

域模型

表示问题域的一部分的类。MemberModel负责其创建和验证。因为服务接收和返回模型，所以模型负责自己的业务逻辑，以验证其正确的构造和使用。例如：如果您尝试在没有用户名的情况下使用MemberModel，则该模型应该会中断。

域服务

域服务采用实体模型并将其转换为域模型据错误的危险信号。

域服务采用域模型并将它们映射到实体，以便将它们发送到后边界。如果后边界（DB/SDK？）无法接受模型，则需要修复DB/SDK。

• 注意：实体符合模型 ，因为持久性是一个细节。域是系统之王，而不是持久性的硬件或表结构。域名永远不会出错

Front Boundaries采用ViewModels并将其转换为域模型，以便将其传递到域中。如果ViewModel未能序列化或映射到域模型，则会出现view/json/xml错误的危险信号。

域服务将域模型返回到前端边界，然后将其映射到ViewModels以便在前端进行通信。如果视图/UI无法接受模型，则需要修复视图。

• 注意：ViewModels符合Models ，因为消费者是一个细节。域是系统之王，而不是用户界面或子应用程序。域名永远不会出错

ViewModel永远不知道实体，因为UI/使用者永远不知道持久性的存在。

核心业务逻辑不应该知道ViewModels或实体。核心业务逻辑仅适用于域模型。这就是控制器及其附近的前端服务存在的原因；映射域模型<>ViewModels。这也是SDK及其附近的后端服务存在的原因；映射DomainModels<>实体。

构建系统时，首先构建域和业务逻辑（希望是TDD）。然后，适配器被放在业务逻辑的前端和后端，这些逻辑决定了传递机制（前端）和依赖关系（服务/持久性）（后端）。但这些前端和后端可能会被剥离，核心业务逻辑仍然存在。

较短版本（TLDR；）：

实体：数据库记录。

领域模型：模型特定的业务逻辑（谷歌的"价值对象"），以表示领域问题中的对象。

ViewModel：视图的页面（或部分）。

不同的人对这些术语的理解有点不同，但我就是这样理解的：

实体-具有标识（ID）的对象，通常来自数据库。很简单的课。

模型——任何业务对象，这是一个有点宽泛的术语。它可以是一个实体，你在项目中创建的一些自定义类等等。它几乎是所有不是视图或控制器/视图模型的东西。

ViewModel——模型和视图之间的某种中介。它调节模型和视图之间的通信，例如应用验证，将更多的模型组合成一个更大的对象等，以便与特定视图进行交互。ViewModel还负责事件处理（例如单击鼠标按钮），因此它向绑定到的视图（WPF）公开命令。

我的理解是，模型是这里的核心概念，它反映了对所解决问题的理解。实体确定模型对象将如何存储在数据库中。Viewmodels决定向最终用户显示Model的哪个部分。

这些术语的定义非常模糊。你会在不同的地方找到不同的定义。

实体：实体表示作为记录保存到数据库中的域对象的单个实例。它有一些我们在表中表示为列的属性。

模型：模型通常表示与问题或域空间相关的真实世界对象。在编程中，我们创建类来表示对象。这些类称为模型，具有一些属性和方法（定义对象行为）。

ViewModel：术语ViewModel源自MVVM（模型-视图-视图模型）设计模式。在某些实例中，视图要渲染的数据来自两个不同的对象。在这样的场景中，我们创建一个模型类，该类由视图所需的所有属性组成。它不是域模型，而是ViewModel，因为特定视图使用它。此外，它不代表真实世界的对象。

有关更多详细信息，请访问我的博客文章：实体与模型与视图模型与数据模型