разберись в вопросе и не пытайся все обобщить настолько что теряется смысл терминов

Все же это усложнение концепта (шаблона) за счет реализации. По сути что у апликейжн леера, что у саги получается одно и то же назначение. Подергать нужные агрегатики в нужном порядке

Implement each business transaction that spans multiple services is a saga. A saga is a sequence of local transactions.

А т.к. агрегат и есть граница транзакции

DoMyVeryImportantUseCase(DoStuff command) {
    val firstThing = firstRepo.get(command.firstThingId)
    val secondThing = secondRepo.get(command.secondThingId)
    val fee = feeCalculation(command.amount)
    // ...
}

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

1. разберись что такое колаборативный домен.
2. разберись в чем проблема распределенных транзакций в условиях колаборативного домена

Как юзкейсы можно:

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

оба примера есть в видосах уди

лучше "обслуживать один юзкейс", так хоть чуть более конкретно

наверное проще будет сразу сказать что CQRS это не паттерн. Это не техническая штука. Это архитектурный стиль который оказывает влияние на то как ты доменную область моделируешь. То есть нельзя взять "я пишу в базу и читаю из вьюшки" и называть это CQRS.

этот responsibility segregation происходит не в коде а на уровне моделирования домена. Ты выбираешь какие вещи команды (работают только с актуальными данными, не должны фэйлиться, клиент не должен ждать пока они обработаются), какие запросы (могут работать с устаревшими данными) и как выстроить тут флоу. Часто это будет влиять на то как у тебя решение в рамках домена будет выглядеть (пример с лондонскими олимпийскими играми у Уди для меня показался наиболее показательным)

а пишу в базу читаю из вьюшки можно просто сказать что CQS на максималках

Соглашусь.

Предположим у меня есть кейс, когда нужно найти товар (агрегат) по id. Напрямую из представления в репозиторий лезть нельзя (или можно?), поэтому будет служба в которой есть этот функционал.
А также есть сценарий создания корзины (другой агрегат), который предполагает, что прежде чем создавать эту корзину надо убедиться, что товары реально существуют. Правильно я понимаю, что в таком случае сервису по созданию корзины использовать сервис по поискку товаров?

все эти агрегаты слои и прочее имеют смысл только если ты собрался стэйт менять. Если только читаешь (надо шмоток json-а клиенту вернуть) можешь из контроллеров просто напрямую в базу ходить

для операций записи и пользователю для UI как правило нужны чуть разные модели данных

Я сиольно упрощаю.

юзкейс это что-то что важно для бизнеса. "оформить заказ", "снять товар с продажи"... вот эти вещи

"забрать из базы" это не юзкейс, это технический булшит

Я базу вообще не упоминул...

Подскажите, пожалуйста, есть ли литература какая-нибудь или что-нибудь другое, где можно почерпнуть то, о чем вы говорите? Может лекции крутых разработчиков?
Мы в команде часто об этом спорим, можно ли напрямую в БД, допустим, из контроллера, если нам просто прочитать данные надо)

Implementing Domain Driven Design by Vaugh Vernon, Domain Driven Design by Eric Evans, Advanced Design of Distributed Systems by Udi Dahan

Только последний вопрос это не из ddd. Это скорее про SRP/DRY

где-то тут ссылка была на Advanced Distributed System Design от Уди Дахан - там 20-30 часов видосов где все это разбирают. Вообще все.