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.