Skip to content

[User] Рефакторинг модуля управления пользователями по принципам DDD #44

@soorq

Description

@soorq

Контекст

Текущий модуль User перегружен инфраструктурными деталями (ORM-декораторы, специфичные для базы данных типы) и выполняет слишком много задач одновременно. Необходимо выделить «Чистую доменную модель» пользователя, которая будет содержать только бизнес-правила (например, правила смены имени, верификации профиля и управления статусами), изолировав её от методов доступа к данным.


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

  • Локация логики: src/modules/user/
  • Инструменты: TypeScript, паттерны Value Objects (для Email, FullName), Domain Events.
  • Логика работы:
    1. Domain Entities: Определение корня агрегата User. Поля сущности должны быть приватными, изменение состояния — только через публичные методы (например, updateProfile(), deactivate()).
    2. Value Objects: Вынос логики валидации формата email и сложных строковых полей в отдельные неизменяемые объекты.
    3. Application Services: Создание обработчиков команд (Command Handlers) для действий: UpdateUserCommand, ChangeUserRoleCommand.
    4. Infrastructure: Реализация репозитория на базе Drizzle ORM/NestJS, который преобразует доменную сущность в схему БД и обратно.

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

  • База: Создан базовый класс AggregateRoot и сущность User без зависимостей от внешних библиотек (кроме типов).
  • Функционал: Реализована логика смены статуса пользователя с генерацией доменного события UserStatusChanged.
  • Лимиты/SLA: Полное отсутствие SQL-логики или вызовов ORM внутри доменного слоя.
  • Интеграция: Настроено сопоставление (Mapping) между UserDomainModel и UserPersistenceModel в слое инфраструктуры.

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

  • Производительность: Избегать загрузки всего профиля пользователя (включая связанные таблицы), если для выполнения бизнес-операции достаточно только базовых полей агрегата.
  • Ошибки: Выбрасывать UserDomainException при попытке нарушения бизнес-правил (например, активация уже активного пользователя).
  • Безопасность: Доменная модель не должна содержать методов, позволяющих массово изменять чувствительные поля без соответствующих проверок разрешений в слое Application.

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions