(Когда и зачем использовать доменные сервисы?)
Продолжаю знакомиться с DDD. Следующий паттерн Domain Services.
Domain Service - это класс, который реализует бизнес-правила, выходящие за рамки одного агрегата.
В Domain-Driven Design (DDD) не вся бизнес-логика уместна внутри агрегатов или сущностей.
Иногда операции:
- Затрагивают несколько агрегатов,
- Зависят от внешних систем (например, проверка кредитного рейтинга),
- Не имеют естественного места в какой-то одной сущности.
Для такой логики создают Domain Services (доменные сервисы).
Отличия от других сервисов в DDD
Domain Service — содержит только бизнес-логику, не зависит от инфраструктуры.Application Service — оркестрирует вызовы Domain-сервисов и инфраструктуры (например, «создать заказ → сохранить в БД → отправить уведомление»).Infrastructure Service — технические детали (отправка почты, запросы к API).Когда использовать Domain Service?
✅ Логика требует нескольких агрегатов.
✅ Зависит от доменных правил, но не принадлежит ни одной сущности (например, проверка сложных условий).
✅ Чистая бизнес-логика без инфраструктурных деталей.
❌ Не используйте, если:
- Логика относится к одному агрегату (лучше поместить в агрегат).
- Нужен доступ к БД, API и т.д. (это Application/Infrastructure Service).
✔️ Плюсы:
- Четкое разделение ответственности.
- Удобство тестирования (чистая логика без побочных эффектов).
❌ Минусы:
- Риск превращения в "God Object" (если сервис делает слишком много).
Domain Services — это мост между агрегатами для сложной доменной логики.
P.s.
Полезная ссылка по теме:
https://enterprisecraftsmanship.com/posts/domain-vs-application-services/
#DDD #DomainServices #CleanArchitecture