Skip to content

[Architecture] Миграция серверной части на принципы Domain-Driven Design (DDD) #42

@soorq

Description

@soorq

Контекст

Текущая архитектура системы имеет признаки «анемичной» модели данных и сильной связности (tight coupling) между бизнес-логикой и инфраструктурными компонентами. Это затрудняет масштабирование, тестирование и понимание сложных бизнес-процессов. Переход на DDD (Domain-Driven Design) необходим для изоляции чистого домена от внешних зависимостей, обеспечения консистентности данных через агрегаты и улучшения модульности системы.


Технические требования

  • Локация логики: Весь backend сервис. Переход от слоев controllers/services/models к структуре по ограниченным контекстам (Bounded Contexts).
  • Инструменты: Основной стек приложения, паттерны: Repository, Unit of Work, Value Objects, Aggregates.
  • Логика работы:
    1. Определение контекстов: Разделение монолита на логические модули (например, Billing, Inventory, Users).
    2. Слой Domain: Создание сущностей (Entities) и объектов-значений (Value Objects), содержащих бизнес-правила. Домен не должен зависеть от ORM или сторонних библиотек.
    3. Слой Application: Реализация сервисов приложений, которые координируют задачи, но не содержат бизнес-логику.
    4. Слой Infrastructure: Реализация интерфейсов репозиториев, работа с БД, внешними API и очередями сообщений.
    5. Слой Interfaces/API: Контроллеры и DTO для взаимодействия с внешним миром.

Цель и критерии приемки (Definition of Done)

  • База: Разработана новая структура каталогов (src/modules/[context]/...) и определены границы агрегатов.
  • Функционал: Логика ключевого бизнес-процесса полностью перенесена в Domain Layer с использованием Domain Services, где это необходимо.
  • Лимиты/SLA: Интроспекция зависимостей подтверждает отсутствие импортов из Infrastructure в Domain. Время отклика не должно деградировать более чем на 5% из-за введения дополнительных слоев абстракции.
  • Интеграция: Обновлены Unit-тесты для доменной логики (без моков БД) и интеграционные тесты для репозиториев.

Важные указания

  • Производительность: Обратить внимание на проблему N+1 при загрузке агрегатов и использовать Eager Loading только там, где это необходимо для соблюдения инвариантов.
  • Ошибки: Использовать доменные исключения (например, DomainException, EntityNotFoundException) для описания нарушений бизнес-логики.
  • Безопасность: Валидация входных данных должна происходить на уровне DTO, а проверка бизнес-инвариантов — внутри сущностей и Value Objects.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions