Lecture
In modern programming, especially in architectures oriented toward complex business domains, it becomes critically important to distinguish between the conceptual levels of data representation. One of the key challenges developers face is confusion between the Entity Model and the Data Model — two models that, despite their outward similarity, serve completely different purposes. In the context of Domain-Driven Design (DDD), where the emphasis is on deep understanding of the domain and building a model that reflects business logic, the distinction between these approaches takes on particular significance. The Entity Model is not just a data structure, but a reflection of entities possessing identity, behavior, and relationships that are meaningful within the business domain. Meanwhile, the Data Model is typically oriented toward storing, transmitting, and transforming information, often in the context of databases, APIs, or external systems. Failing to understand these differences can lead to architectural mistakes, loss of model expressiveness, and ultimately a decline in software solution quality. The purpose of this article is to examine in detail how the Entity Model and Data Model differ, how they relate to DDD principles, and why clearly distinguishing between them is not merely a theoretical exercise but a practical necessity for building robust, scalable, and understandable systems.
In terms of DDD (Domain-Driven Design), the distinction between Entity, Model, and DataModel within a context can be explained as follows:
Has a unique identity (ID) that remains unchanged even when its properties change.
What matters is the object's identity, not just its data.
Example:
class Order
{
Guid Id; // unique identifier Customer Customer;
List<OrderLine> Lines; DateTime CreatedAt;
}
Here, the Order is an Entity, because it exists as an object even if the composition or date of the order changes.
This is the domain model that reflects business logic.
Consists of Entity, Value Object, Aggregate, Service, and so on.
Defines how the domain lives and works.
The Domain Model is responsible for invariants and rules (for example, an order cannot be confirmed without at least one item).
This is a model tailored for storing and transmitting data (ORM entities, DTOs, etc.).
It may coincide in structure with the Domain Model, but essentially plays a different role:
Entity Framework classes (table mappings).
DTOs for an API.
The DataModel is often closer to the database schema than to business logic.
Example:
class OrderDataModel
{
public Guid Id { get; set; }
public Guid CustomerId { get; set; }
public DateTime CreatedAt { get; set; }
}
This is already a DataModel, with no business logic, just a data container.
Entity – part of the Domain Layer (the heart of DDD).
Domain Model – a collection of entities, value objects, aggregates, services → reflects the business.
DataModel – part of the Infrastructure Layer, used for storing and transmitting data, contains no business logic.
This diagram illustrates the concept of DDD (Domain-Driven Design) broken down by layers:
Domain (Domain Layer)
Contains the Domain Model – the domain model reflecting business logic.
Inside the Domain Model are Entities, which have identity and are the central objects of the business logic.
Application (Application Layer)
Responsible for using domain logic in specific scenarios.
Mediates between Domain and Infrastructure.
Infrastructure (Infrastructure Layer)
Contains the DataModel, which is responsible for storing and transmitting data (for example, ORM models or DTOs).
The DataModel is linked to the Domain Model: data is loaded from the infrastructure into domain entities and back.
The arrows in the diagram show the interaction:
The Entity inside the Domain Model defines the business logic.
The DataModel is used by the infrastructure and is converted into domain objects (and vice versa).
The Application layer coordinates the exchange between the domain and the infrastructure, but does not itself contain business rules.
Entity: Order
OrderId identifier
List of items (OrderLine)
Status (Created, Paid, Shipped)
Business rules:
an order cannot be confirmed without items;
an order cannot be cancelled after shipment.
Value Object: Money
Currency + amount.
Used in order lines.
Domain Service: PaymentService
Verifies the correctness of the payment.
Scenario: "Create order".
Accepts cart data.
Calls Order.Create(...).
Saves the result via the repository.
Scenario: "Pay for order".
Loads the order by ID.
Calls order.Pay(paymentInfo).
Passes the changes to storage.
DataModel: OrderDataModel (an ORM object or a database table):
class OrderDataModel {
public Guid Id { get; set; }
public Guid CustomerId { get; set; }
public string Status { get; set; }
public DateTime CreatedAt { get; set; }
}
There is no business logic here — only structure for storage and mapping.
Relationship per the diagram:
OrderDataModel is loaded from the database → converted into Order (Entity).
Order applies rules (for example, checking payment).
After changes, the data is converted back into OrderDataModel and saved to the database.
Entity = an object with identity within the Domain Model.
Model (Domain Model) = the entire domain model (entities + logic).
DataModel = a data model for the database or API, with no business logic, a technical layer.
Separating the concepts of Entity Model and Data Model is not a matter of terminology, but the foundation of architectural thinking in domain-driven design. The Entity Model is a way to express the essence of business objects, their behavior, and their uniqueness within the domain, whereas the Data Model serves technical purposes: storage, serialization, integration. In DDD this distinction becomes especially important, since it is through the Entity Model that we build the Refined Model, which lets the business speak the same language as development. Trying to mix these levels leads to a loss of expressiveness, increased maintenance complexity, and reduced system flexibility. A correct understanding and application of these models not only improves the architecture but also increases resilience to change, eases communication between teams, and produces a software solution that truly reflects the logic and values of the business. Ultimately, the distinction between the Entity Model and the Data Model is not merely a technical nuance, but a manifestation of a mature approach to design, in which each model has its place and plays its role in the overall symphony of the architecture.
Comments