Clean Architecture #6. Domain Итак, вы уже знаете, Domain — это сердце всего приложения. Он не должен зависеть от HTTP, базы данных, фреймворка и любых других внешних зависимостей. Теперь разберёмся, а что мы размещаем в домене? Как правило это: • сущности (Entities) • интерфейсы (Interfaces) • бизнес-правила (Business Rules) • доменные ошибки (Domain Errors) Как видите, здесь нет ничего из «внешнего мира». В том числе и декораторов от ORM. Взглянем на пример сущности из демонстрационного репозитория: export class User { constructor( public readonly id: string, public readonly email: string, public readonly passwordHash: string, ) {} } Это самый обычный класс, без каких-либо декораторов от ORM или других примочек для сериализации. Нет здесь и импорта каких-либо библиотек. В более реалистичном варианте сюда могут быть добавлены инварианты. Например: if (!email.includes('@')) { throw new InvalidEmailError() } Именно здесь следует проверить корректность состояния сущности, а не в контроллере или, скажем, в репозитории. Теперь посмотрим на контракт для репозитория. Он выглядит так: export interface UserRepository { save(user: User): Promise<void> findByEmail(email: string): Promise<User | null> } Домен определяет, ЧТО ему необходимо, но ничего не говорит о способе реализации. Она может быть какой угодной. Домен говорит, что ему нужен способ сохранить и найти пользователя. Как это будет реализовано — его абсолютно не волнует. По факту это и есть Dependency Inversion на практике. 🎯 Простой чек-лист Выполнить проверку и найти нарушения не сложно. Само собой, в реальном проекте для этого настраиваются дополнительные правила линтера. Но есть ещё один способ. Он отлично подходит, когда вы только начинается вносить изменения в доменный слой. Просто задайте себе вопрос: сможет ли работать ваша бизнес-логика если вы удалите, например, SQLite / Express / Prisma / Axios или любую-другую библиотеку. Если ответ — «Да», ваш домен действительно изолирован. Если «нет», значит нарушены правила и зависимости уже торчат наружу. Итак, домен — это место, где формируются правила игры. Всё остальное помогает доставить данные внутрь и обратно. #clean_architecture