What is a Domain Model

A domain model is a visual representation of real situation objects in a domain. A domain is an area of concern. Its used to refer to the area you are dealing with. The model is a diagram, for domain models the class diagram UML is mostly used. The class diagram is only used for the notation. The term domain model does not mean a set of diagrams describing software classes.

So for example imagine a store. For that store you want to build a brand new Point Of Sale system (lets call it POS system). A POS system is a computerized application used to record sale and handle payments. So you focus on the domain of the POS system. Now you will conceptualize the objects that will be used for this system. So you will get objects like: Sale, Payment, Register, Item etc. In a domain model you model these objects and draw associations between them so that you have an high level idea how this system will work. An example of the POS domain model will be like this:

Answering from perspective of Eric Evans's "Domain-Driven Design: Tackling Complexity in the Heart of Software" book:

[A domain] model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

Practically it means the following. On the input we have domain experts, domain knowledge sources and requirement for a software product. Modeling would mean eliciting the relevant [for the software under the development] part of that domain knowledge and representing it somehow. If I understood the author correctly, the model can be represented in many ways: as a text, as diagrams, as a code, in form of oral communication. The model is updated in parallel with iterative software development, being reworked for the need of the software development.

So a domain model is a selective and structured representation of domain knowledge relevant for a given software development project.

Domain model is a collection of constructs that accurately models one particular business domain. Simply put, it’s a collection of entities, enumerations, value objects, exceptions/custom exceptions, interfaces, services, etc. All of that represents the domain model. Anything that has any impact in describing the business domain. On the other hand, any construct that doesn’t take part in this description; the UI code, infrastructure related code, persistence objects, various tools, etc; are considered as third-party/outer concerns in the context of DDD.

Check out this short article

https://fiseni.com/posts/what-is-a-domain-model/

in a super simple sentence I can say:

Domain model is an abstraction of domain, expressed as code implementation which is a view not reality of business use case.