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

определение мартина сбивает с толку, т.к. может показаться, что сам устойчивый компонент должен быть абстрактным (аки помеченным abstract в каком-то языке)

типа отдать курьеру

это, кстати, дополняет мой ответ о тестировании и зачем делать моки

а почему она вручную тыкается?

Потому что приходит курьер. Ему менеджер отдает товар и тыкает - отдал товар

в клине рассказывается о SAP и SDP, которые вместе дают DIP

в какой момент во всём это происходит настоящая оплата? Ну то есть деньги покупатель когда отдаёт? В момент когда к нему курьер приходит с товаром?

Когда захочет. Есть баланс, его пользователь пополняет. Как только его пополнят, с него перетекает на товар. Если баланса хватает товар считается оплаченным

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

Что то пока мне этого не понять... бизнес сервис жонглирует конкретными сущностями, и поэтому он абстрактный максимально, в моем понимании как раз конкретика полная... видимо я не так понимаю :(

от сюда и вот эти все правила мол не нарушай слои, не играй с сущностями в контроллере на прямую и т.д. это просто применение базового правила из чистого кода

а "отдал товар" менеджер тыкает для чего?

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

чистый код (с)

я думаю листинг приводить не надо)

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

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

Order {id, isPaymentCompleted }

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

получается, что никакая у тебя не постоплата. Покупатель просто оплачивает товар из кошелька. Момент списания тугриков с кошелька и будет моментом оплаты. Зачем проверять хватает ли денег на кошельке, если до этого у покупателя уже деньги списались с кошелька? Ведь в момент списания они у него были

нет, я не говорю о дублировании таблиц в базе, я говорю об ограничении маппингов на уровне орм в твоём приложении. таблица всё ещё будет одна, поэтому всё будет косистентно