Можно сделать некий интерфейс TransactionInterface для запуска/завершения/отката и пусть инфраструктура это реализует, а использовать будем там, где у нас бизннс-логика

Елисеев в курсе про магазин на yii2 делал интересный TransactionManager в сервисном слое

https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/services/TransactionManager.php

TransactionInterface работатет только в случае, если все хранится в одной бд, как только ты раскидаешь по разным хранилищам, реализация такого интерфейса станет крайне сложной.

Управления транзакциями должно быть на уровне сервисов приложения

Транзакции могут быть и частью бизнес-логики. Особенно распределённые.

Это об этом я и писал выше, грубо говоря один метод такого сервиса - это одна бизнес-транзакция, а вот внутри уже может быть несколько транзакций в разных хранилищах.

бизнес-транзакция - это по сути не какая-то реализация, а в каждом случае должно индивидуально разруливаться в коде получается?

Да, это может быть просто оберткой над транзакцией орм, а может быть и сложная логика в распределенной системе.

Но ведь бизнес-логика не знает про реализацию на инфраструктурном уровне... Это одна БД или это разные БД. Как это может быть обёрткой над ORM

Для наглядности обсуждаемого вопроса.

У менять есть два репозитория и две сущности. Надо их транзакционно сохранить. Структура такая:

Application
  Service
    ::saveEntities($entity1, entity2)
Domain
  Entity
    Entity1
    Entity2
    Entity1RepositoryInterface
    Entity2RepositoryInterface
Infrastructure
  Repository
    Entity1Repository
    Entity2Repository

   
Вот метод saveEntities сам должен траназакцию организовать?
Или надо в инфраструктуре ещё добавить сервис, который будет отвечать за транзакционное сохранение?

Это сервис приложения, на уровне бизнес-логики это реализуется в виде агрегата, поскольку он всегда сохраняется атомарно.

"сервис приложения" - это инфраструктурный слой?

Получается вообще такой задачи не должно быть "Сохранить две сущности". Надо сохранить - делай агрегат, под него репозиторий?

Он знает об инфраструктуре, грубо говоря туда выносится некоторая общая логика контроллеров.

Можешь на приведённом примере сказать, что должно происходить в методе saveEntities?

Давай реальный кейс, без этого сложно сказать

Ну вот на примере контрагентов. Есть сущность контрагента, есть сущность физлицо, есть сущность организация. Есть метод для сохранения одновременно организации и контрагента:

Application
  Service
    ::saveOrgContractor($contractor, $org)
Domain
  Entity
    Contractor // Контрагент
    Fizik // ФизЛицо
    Org // Организация
Infrastructure
  Repository
    ContractorRepository
    FizikRepository
    OrgRepository

Если это из вчерашнего обсуждения, то Contractor - это один агрегат и его сохранение разруливает репозиторий

То есть application должен из присланных DTO слепить агрегат и дальше репозиторий его сохранить, так?

Да. Я не особо вникал во вчерашнюю писанину, но сущность контрактор должна быть агрегатом, который содержит конкретные типы.