Архитектурные слои

✅ Domain Layer

• Entities / Aggregates — инкапсулируют бизнес-правила и обладают идентичностью
• Value Objects — те же, но без идентичности (immutable объекты)
• Domain Services — используются только если бизнес-логику невозможно естественно поместить ни в Aggregates, ни в Value Objects.
  • Важно: они не знают о репозиториях, не ходят в базу. Только "чистая" бизнес-логика
  • Пример: расчёт стоимости заказа с учётом скидок, где участвуют несколько агрегатов (заказ и пользователь)
  • Критерий использования: когда операция концептуально не принадлежит ни одной сущности, но является частью доменной модели

✅ Application Layer

• Application Services / Use Cases / Interactors (названия — вкусовщина)
  • Оркестрируют вызовы агрегатов, доменных сервисов, репозиториев, внешних API
  • Содержат инфраструктурные детали (но не реализуют их) — например, вызывают order_repo.get_by_id(...), но не знают, как именно работает репозиторий
  • Представляют API доменной модели для внешнего мира
  • Переводят запросы из внешних слоев в вызовы доменной модели и обратно

⚙️ Infrastructure Layer

• Infrastructure Services — реализуют технические детали (репозитории, внешние API, email-сервисы)
• Используются Application Services, но никогда не содержат бизнес-логику

🔁 Взаимодействие между контекстами (Bounded Contexts)

• Orchestrator / Coordinator — реализация use case между контекстами
• Событийное взаимодействие (Event-Driven Architecture) — предпочтительный подход для поддержания автономности контекстов

Подробная таблица сравнения