Entity vs Model vs View Model

The term "Model" is ambiguous. They are all models.

Entity Model

A class which closely resembles structure in persistence. A MemberEntity is a model which represents one member row in the Members table in a database. Not strictly tied to a Database, but some entity of some persistence. Typically has an "ID" property such as "int MemberID".

ViewModel

A class which closely resembles structure on a View/UI. A MemberViewModel is a model which represents one member to be displayed on a Members View/UI on the frontend of an application. Not strictly tied to the MV* pattern.

Notice

...that the above two models represent communication on the boundaries of the application. That is, the front boundary (entry point) which receives communication (user events and communication via protocol) to initiate business rules; And the back boundary which takes commands from business rules to open communication with other systems (such as databases or other endpoints).

Domain Model

A class which represents part of the problem domain. The MemberModel is responsible for its creation and validation. Because services take in and return out models, the models are responsible for their own business logic which validates their correct construction and usage. E.G.: A MemberModel should break if you try to use it without a UserName.

Domain Services

Domain Services take Entity Models and transform them into Domain Models so said services can work with the models. If an Entity comes in from the back boundary and fails to serialize or map into a Domain-Model, there is a red flag that the data is bad.

Domain Services take Domain Models and map them to Entities in order to send them out the back boundary. If the back boundary (DB/SDK?) fails to accept the model, the DB/SDK needs to be fixed.

• Note: Entities conform to Models because persistence is a detail. The domain is the king of a system, not the hardware or table-structure of persistence. The Domain is never wrong.

Front-Boundaries take ViewModels and transform them to Domain Models so they can be passed into the Domain. If a ViewModel fails to serialize or map into a Domain-Model, there is a red flag that the view/json/xml is bad.

Domain Services return Domain Models to the front boundary, which are then mapped to ViewModels in order to communicate out the front. If the View/UI fails to accept the model, the View needs to be fixed.

• Note: ViewModels conform to Models because consumers are a detail. The domain is the king of a system, not the UI's or Sub-Apps consuming them. The Domain is never wrong.

A ViewModel NEVER Knows about an Entity because a UI/Consumer never knows that persistence even exists.

Core Business-Logic should not know about ViewModels or Entities. Core Business-Logic only works with Domain Models. That's why Controllers, and Frontend-Services near them, exist; To map Domain Models <=> ViewModels. That's also why SDK's, and Backend-Services near them, exist; To map DomainModels <=> Entities.

When a system is built, the Domain and Business Logic are built first (Hopefully TDD). Then adapters are put on the Front and Back of the business logic which determine the Delivery-Mechanism (frontend) and the Dependencies (Service/Persistence) (Backend). But those frontends and backends could be ripped out, and the core business logic still exists.

Shorter Version (TLDR;):

Entity: Database Record.

Domain Model: Model-specific business logic (Google "Value Object") to represent an object in the Domain Problem.

ViewModel: Page (or section) of a View.

The definition of these terms is quite ambiguous. You will find different definitions at different places.

Entity: An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our tables.

Model: A model typically represents a real world object that is related to the problem or domain space. In programming, we create classes to represent objects. These classes, known as models, have some properties and methods (defining objects behavior).

ViewModel: The term ViewModel originates from the MVVM (Model View ViewModel) design pattern. There are instances in which the data to be rendered by the view comes from two different objects. In such scenarios, we create a model class which consists of all properties required by the view. It’s not a domain model but a ViewModel because, a specific view uses it. Also, it doesn’t represent a real world object.

For more details visit my blog post: Entity vs Model vs ViewModel vs DataModel

My understanding is that the Model is central notion here, it reflects the understanding of the problem being solved. The Entities determine how Model objects will be stored in database. The Viewmodels determine what part of Model is gonna be shown to the end user.

Different people understand these terms a bit differently, but this is how I understand it:

Entity - object that has an identity (ID), usually comes from a database. Pretty simple class.

Model - any business object, this is a kinda broad term. It can be an entity, some custom class you've created in your project etc.. It's pretty much everything that isn't a view nor a controller/viewmodel.

ViewModel - some kind of a mediator between a model and the view. It modulates the communication between the model and the view, for instance applies validation, combines more models into one bigger object etc., for the purposes of the interaction with the specific view. ViewModel is also responsible for event handling (button mouse clicks for instance), so it exposes commands to the view you bind to (WPF).