Различие между Entity, Domain Model, DataModel в контексте DDD кратко

В современном программировании, особенно в архитектурах, ориентированных на сложные бизнес-домены, становится критически важным различать концептуальные уровни представления данных. Одним из ключевых вызовов, с которым сталкиваются разработчики, является путаница между Entity Model и Data Model — двумя моделями, которые, несмотря на внешнюю схожесть, служат совершенно разным целям. В контексте Domain-Driven Design (DDD), где акцент делается на глубоком понимании предметной области и построении модели, отражающей бизнес-логику, различие между этими подходами приобретает особую значимость. Entity Model — это не просто структура данных, а отражение сущностей, обладающих идентичностью, поведением и связями, которые имеют смысл внутри бизнес-домена. В то время как Data Model, как правило, ориентирована на хранение, передачу и трансформацию информации, часто в контексте баз данных, API или внешних систем. Непонимание этих различий может привести к архитектурным ошибкам, потере выразительности модели и, в конечном счете, к снижению качества программного решения. Цель данной статьи — подробно рассмотреть, чем отличаются Entity Model и Data Model, как они соотносятся с принципами DDD, и почему их четкое разграничение является не просто теоретическим упражнением, а практической необходимостью для построения устойчивых, масштабируемых и понятных систем.

В терминах DDD (Domain-Driven Design) различие между Entity, Model и DataModel внутри контекста можно пояснить так:

Entity (Сущность)

• Имеет уникальную идентичность (ID), которая остается неизменной даже при изменении ее свойств.

• Важна личность объекта, а не только его данные.

• Пример:

  class Order 
  {
   Guid Id; // уникальный идентификатор Customer Customer; 
   List<OrderLine> Lines; DateTime CreatedAt;
  } 

  Здесь заказ (Order) – это Entity, потому что он существует как объект, даже если изменить состав или дату заказа.

Model (Domain Model)

• Это предметная модель, которая отражает бизнес-логику.

• Состоит из Entity, Value Object, Aggregate, Service и т. д.

• Определяет как предметная область живет и работает.

• Domain Model отвечает за инварианты и правила (например, заказ нельзя подтвердить без хотя бы одного товара).

DataModel (или Persistence Model / Database Model)

• Это модель, заточенная под хранение и передачу данных (ORM-сущности, DTO и т. п.).

• Может совпадать по структуре с Domain Model, но по сути выполняет другую роль:

  • Entity Framework классы (табличные маппинги).

  • DTO для API.

• DataModel часто ближе к схеме базы данных, чем к логике бизнеса.

• Пример:

  class OrderDataModel
  { 
     public Guid Id { get; set; } 
     public Guid CustomerId { get; set; } 
     public DateTime CreatedAt { get; set; } 
  } 

  Это уже DataModel, без бизнес-логики, просто контейнер данных.

В контексте DDD и слоев:

• Entity – часть Domain Layer (сердце DDD).

• Domain Model – совокупность сущностей, объектов-значений, агрегатов, сервисов → отражает бизнес.

• DataModel – часть Infrastructure Layer, используется для сохранения и передачи данных, не содержит бизнес-логики.

Эта схема иллюстрирует концепцию DDD (Domain-Driven Design) в разрезе слоев:

1. Domain (Доменный слой)

   • Содержит Domain Model – предметную модель, отражающую бизнес-логику.

   • Внутри Domain Model находятся Entity (сущности), которые имеют идентичность и являются центральными объектами бизнес-логики.

2. Application (Слой приложений)

   • Отвечает за использование доменной логики в конкретных сценариях.

   • Посредник между Domain и Infrastructure.

3. Infrastructure (Инфраструктурный слой)

   • Содержит DataModel, которая отвечает за хранение и передачу данных (например, ORM-модели или DTO).

   • DataModel связана с Domain Model: данные загружаются из инфраструктуры в доменные сущности и обратно.

На схеме стрелки показывают взаимодействие:

• Entity внутри Domain Model определяет бизнес-логику.

• DataModel используется инфраструктурой и преобразуется в объекты предметной области (и наоборот).

• Application слой координирует обмен между доменом и инфраструктурой, но сам бизнес-правил не содержит.

Пример для интернет-магазина:

Domain (Доменный слой)

• Entity: Order (Заказ)

  • Идентификатор OrderId

  • Список товаров (OrderLine)

  • Статус (Created, Paid, Shipped)

  • Бизнес-правила:

    • нельзя подтвердить заказ без товаров;

    • нельзя отменить заказ после отправки.

• Value Object: Money

  • Валюта + сумма.

  • Используется в строках заказа.

• Domain Service: PaymentService

  • Проверяет корректность платежа.

Application (Слой приложений)

• Сценарий: "Создать заказ".

  • Принимает данные корзины.

  • Вызывает Order.Create(...).

  • Сохраняет результат через репозиторий.

• Сценарий: "Оплатить заказ".

  • Загружает заказ по ID.

  • Вызывает order.Pay(paymentInfo).

  • Передает изменения в хранилище.

Infrastructure (Инфраструктурный слой)

• DataModel: OrderDataModel (ORM-объект или таблица в БД):

  class OrderDataModel { 
    public Guid Id { get; set; } 
    public Guid CustomerId { get; set; } 
    public string Status { get; set; } 
    public DateTime CreatedAt { get; set; } 
  } 

• Здесь нет бизнес-логики — только структура для хранения и маппинга.

Связь по схеме:

• OrderDataModel загружается из базы → преобразуется в Order (Entity).

• Order применяет правила (например, проверка оплаты).

• После изменения данные снова превращаются в OrderDataModel и сохраняются в БД.

Итого:

• Entity = объект с идентичностью внутри Domain Model.

• Model (Domain Model) = вся предметная модель (сущности + логика).

• DataModel = модель данных для БД или API, без бизнес-логики, технический слой.

Разделение понятий Entity Model и Data Model — это не вопрос терминологии, а фундамент архитектурного мышления в предметно-ориентированном проектировании. Entity Model — это способ выразить суть бизнес-объектов, их поведение и уникальность в рамках домена, тогда как Data Model служит техническим целям: хранению, сериализации, интеграции. В DDD это различие становится особенно важным, поскольку именно через Entity Model мы строим Уточненную Модель (Refined Model), которая позволяет бизнесу говорить на одном языке с разработкой. Попытка смешать эти уровни приводит к потере выразительности, усложнению сопровождения и снижению гибкости системы. Правильное понимание и применение этих моделей позволяет не только улучшить архитектуру, но и повысить устойчивость к изменениям, облегчить коммуникацию между командами и создать программное решение, которое действительно отражает логику и ценности бизнеса. В конечном счете, различие между Entity Model и Data Model — это не просто технический нюанс, а проявление зрелого подхода к проектированию, где каждая модель занимает свое место и выполняет свою роль в общей симфонии архитектуры.