DDD Entity != ORM Entity: Почему это важно и как избежать "болевых точек" в архитектуре
Часто в проектах, которые разрабатываются с использованием подхода Domain Driven Design, возникает соблазн использовать одну и ту же Java сущность для двух принципиально разных целей. Один класс используется и как бизнес логика (DDD Entity), и как ORM сущность (часто это мотивируется следованию принципу DRY(Don't Repeat yourself), хотя он не имеет к этому никакого отношения). Но на практике такое слияние приводит к серьезным проблемам в поддержке и дальнейшем развитии.
Почему Сущность DDD и Сущность ORM — это разные вещи?
Разная природа и ответственность:
- Сущность DDD - это ядро бизнес-домена. Она инкапсулирует состояние и поведение, важное для бизнес-процессов. Ее идентичность определяется бизнес-правилами (например OrderId для заказа). Ее цель моделировать бизнес-акторов и их жизненный цикл. Сущность DDD отражает бизнес-ценность
- Сущность ORM - это прежде всего, отображение схемы/таблицы/строки бызы данных в класс или запись в коде. Ее задача - описать структур данных и их связей, механизмы их сохранения и загрузки.
Разная скорость изменения:
- Сущность DDD должна быть гибкой и быстро адаптируемой к изменениям бизнес-требований. Новые правила, состояния и поведения появляются часто. Это нормально и желательно для эволюции домена.
- Сущность ORM - обычно меняется редко. Изменения влекут за собой изменение схемы базы данных. Это дорогая операция и требует планирования, тестирования, может быть рискованной в продакшен среде, часто блокирует таблицы, влияет на производительность. Разработчики и архитекторы инстинктивно избегают таких изменений.
К чему приводит смешивание
Когда DDD сущность становится ORM сущностью, происходит следующее:
- Страх изменений: необходимость быстро изменять бизнес-логику в DDD-сущности напрямую упирается в необходимость миграции БД. Это создает огромное сопротивление изменению доменного слоя — самого важного для бизнеса!
- Костыли и Обвязки: Чтобы избежать изменения схемы БД при изменении бизнес-требований, разработчики начинают придумывать обходные пути:Логика переносится в сервисный слой (нарушая инкапсуляцию DDD-сущности).Появляются "транспортные" DTO, копирующие часть состояния сущности для разных нужд.Поля ORM Entity используются не по назначению, хранят "закодированную" бизнес-информацию.Сложные, неочевидные запросы (JPQL/HQL) пытаются компенсировать несоответствие модели и схемы.Код становится запутанным, хрупким и тяжелым для понимания и тестирования.
- Нарушение Принципов: Смешивание ответственности нарушает Single Responsibility Principle (SRP) и затрудняет соблюдение ограниченных контекстов (Bounded Contexts) из DDD. Доменный слой становится зависимым от инфраструктурных деталей ORM.
Заключение
Смешение DDD и ORM — это удобно в начале, но очень дорого в долгосрочной перспективе.
Правильное разделение ответственностей позволяет создавать более устойчивые, масштабируемые и гибкие приложения.
DDD-сущность отражает бизнес, ORM-сущность отражает данные. И если начать видеть эту разницу, архитектурные решения станут намного осознаннее и эффективнее.
Мой канал в telegram