Ссылка на репозиторий: https://github.com/codeliner/php-ddd-cargo-sample/tree/master/CargoBackend/src

А почему у него интерфейс репозиторий лежит в домене (model), а используется в app (BookingService)?

Честно говоря не очень понял вопрос. Скорее это должно быть на app.

интерфейс менеджера транзакции в application и там же используется

Интерфейс транзакшн-менеджера и усё? А где интерфейс клиента? Как предполагается реализовывать распределенную транзакцию?

Тут подразумевается нераспределеная транзакция, если я правильно понял

Нераспределенная транзакция, это когда клиент управляет транзакцией в одном соединении с сервером. Если в двух и более - транзакция распределенная.

Немного не в тему, возможно холиварно, но всё же. Как же относятся к CQS, вот допускаю очевидную ошибку - несоответствие типов, или что то еще?:

interface AwesomeWork {
    pub fun workForFortyHourInWeekAndHaveNoNothing(): void;
    pub fun getReward(): tinyint;
}

interface HarshReality {
    pub fun sendKindsToSchool(smallint $greatTwoOrEqueal): void;
    pub fun useAllYouStrenghToMakeMoney(int256 $hoursInWeek): void;
    pub fun getRewardForGoodGuy(): tinyint;
}

interface MyLife {
   pub fun myfreeHours(smallint $freeHours): void;
   pub fun myWorthlessHours(int256 $badHours): void;
   pub fun getMeaningOfLife(): int; # not 42!!
}

Нет плохих или неплохих подходов.

У этого подхода есть только один недостаток - можно попасть в ситуацию с длинными транзакциями (мол сначала с одним чёт сделаем но ещё не коммитим а потом со вторым). Так же важно понимать по каким причинам будут фэйлится транзакции и т.д.

А так это базовый вариант, он прост в реализации но достаточно "влоб".

Вот вот, тут сразу саги всплывают, вот и не пойму как правильно для бизнеса это исполнить. Например для обмена на бирже, ты сразу бы передал ExchangeId, а потом по нему спрашивать состояние, но не всегда же бывает такое. Например говорит твоя - устрой мне coolDayOfVulgar($somewhere): $anybody
Вот и понимаешь, что каждый паттерн, в своей ситуации работает.

Меня смущает, что знания о транзакциях перешли на application-уровень и позволяют обернуть в транзакции, что угодно...

А вот это самая первая ошибка! Путаем знания бизнеса и свои. Нельзя так, как бы вы это решили? Нет тут прикладного, есть просто интерфейсы.

А на каком уровне ты хочешь транзакциями рулить?

в инфраструктуре

Это про реализацию. А какой уровень знает где границы операций

Cross cutting concerns? Ни?

Меня тут больше интересовал бы вопрос: "А как это все откатывать?"

Rollback и все, потому это и удобно.

Ни.