Контекст
Текущая архитектура системы имеет признаки «анемичной» модели данных и сильной связности (tight coupling) между бизнес-логикой и инфраструктурными компонентами. Это затрудняет масштабирование, тестирование и понимание сложных бизнес-процессов. Переход на DDD (Domain-Driven Design) необходим для изоляции чистого домена от внешних зависимостей, обеспечения консистентности данных через агрегаты и улучшения модульности системы.
Технические требования
- Локация логики: Весь
backend сервис. Переход от слоев controllers/services/models к структуре по ограниченным контекстам (Bounded Contexts).
- Инструменты: Основной стек приложения, паттерны:
Repository, Unit of Work, Value Objects, Aggregates.
- Логика работы:
- Определение контекстов: Разделение монолита на логические модули (например,
Billing, Inventory, Users).
- Слой Domain: Создание сущностей (
Entities) и объектов-значений (Value Objects), содержащих бизнес-правила. Домен не должен зависеть от ORM или сторонних библиотек.
- Слой Application: Реализация сервисов приложений, которые координируют задачи, но не содержат бизнес-логику.
- Слой Infrastructure: Реализация интерфейсов репозиториев, работа с БД, внешними API и очередями сообщений.
- Слой Interfaces/API: Контроллеры и DTO для взаимодействия с внешним миром.
Цель и критерии приемки (Definition of Done)
Важные указания
- Производительность: Обратить внимание на проблему
N+1 при загрузке агрегатов и использовать Eager Loading только там, где это необходимо для соблюдения инвариантов.
- Ошибки: Использовать доменные исключения (например,
DomainException, EntityNotFoundException) для описания нарушений бизнес-логики.
- Безопасность: Валидация входных данных должна происходить на уровне DTO, а проверка бизнес-инвариантов — внутри сущностей и Value Objects.
Контекст
Текущая архитектура системы имеет признаки «анемичной» модели данных и сильной связности (tight coupling) между бизнес-логикой и инфраструктурными компонентами. Это затрудняет масштабирование, тестирование и понимание сложных бизнес-процессов. Переход на DDD (Domain-Driven Design) необходим для изоляции чистого домена от внешних зависимостей, обеспечения консистентности данных через агрегаты и улучшения модульности системы.
Технические требования
backendсервис. Переход от слоевcontrollers/services/modelsк структуре по ограниченным контекстам (Bounded Contexts).Repository,Unit of Work,Value Objects,Aggregates.Billing,Inventory,Users).Entities) и объектов-значений (Value Objects), содержащих бизнес-правила. Домен не должен зависеть от ORM или сторонних библиотек.Цель и критерии приемки (Definition of Done)
Domain Layerс использованиемDomain Services, где это необходимо.InfrastructureвDomain. Время отклика не должно деградировать более чем на 5% из-за введения дополнительных слоев абстракции.Важные указания
N+1при загрузке агрегатов и использоватьEager Loadingтолько там, где это необходимо для соблюдения инвариантов.DomainException,EntityNotFoundException) для описания нарушений бизнес-логики.