я тоже стараюсь делать все как можно проще без сотни абстракций, и мне очень логично делать так:

- репозитории - абстракция над sql бд, с ним связаны все операции чтения/записи в бд
- сервисы /usecases - сама бизнес логика
- views/controllers - понятно что

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

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

ну и это все чисто для write model. для рид моделек мне вполне норм если будет некий сервис который на выход возвращает структурку. И если структурка в json response преобразуетсяс мидлварвами, а http запросы можно конвертировать на вход этому сервису, то он может быть и контроллером и "репозиторием" и чем хочешь. Без какого либо разделения

всеравно эту херь только с базой покрывать

это мне сложновато пока, довольствуюсь подходом выше пока что))

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

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

ну и это все чисто для write model. для рид моделек мне вполне норм если будет некий сервис который на выход возвращает структурку. И если структурка в json response преобразуетсяс мидлварвами, а http запросы можно конвертировать на вход этому сервису, то он может быть и контроллером и "репозиторием" и чем хочешь. Без какого либо разделения

ну вот я "стаблю" все методы всех зависимостей. пракило такое. которое часто люди игнорируют а потом кричат что с мок фреймворками неудобно и хрупкие тесты.

+ отдельно кафй когда сайд эффекты void - их не надо определять явно в стабах/моках.

потому мне оч больно когда есть некий "репозиторий" и у него скажем 10 методов, 2 из которых юзаются везде а остальные 8 в одном или двух местах максимум

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

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

1. Зачислить денег на счет
2. Перевести деньги со счета на счет (снять с одного, зачислить на другой)
3. Оплатить товар (денежный перевод плюс резервирование товара плюс передача заказа в отдел доставки)

я оч давно не работал с скидками и промокодами потому мне оч сложно комментировать че там как делать и где там какие правила да инварианты.

что из этого юзкейс, сага или еще какая хрень?

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

а эктор как пользователь продукта или эктор как часть дизайна кода?

дальше это вопрос как ты дробишь логические транзакции. В простых кейсах когда нет колаборации или когда ты там локами обмаываешься - можно в "юзкейсе" просто втупую подряд вызовы записать и вжух все логические транзакции в одном месте описаны. Удобно. Особенно кггда можно все это одной транзакцией в базе закрыть.

А можно после каждой логической транзакции кидать ивент и запускать следующую логическую транзакцию. Это уже можно сагами описывать и компенсирующие действия делать. Это когда у тебя более сложные взаимодействия, зависимости и более жесткие требования по времени проведения операции для пользователя. Мол eventual consistency и вот это все

но условно говоря должен быть кто-то кто в конце скажет "заказ оформлен". И вот это - юзкейс.

а вот например "просмотреть историю заказов за день" - это юзкейс или просто метод в том же репо? ведь логик почти нету, по сути тупо sql запрос