это типичный подход из какого-нибудь тактикал-ддд или при проектировании микросервисов

Пользователь заказывает товар. У него на балансе -1000. Товар проходит стадиб производства и лежит на складе. Ему звонят (это тема конечно странная на честном слове) - мол, дорогой, пополни баланс

Ммм интересно, спасибо. ГРубо говоря две сущности из разных контекстов читают данные из одной таблицы

типа того. ну или там под разные сущности делать свои вьюшки, как вариант

👍

это и есть секрет разделения контекстов в ddd) вместо 1 класса знающего все ответы, много специализированных для разных областей применения

@dpr_dev немного дополню на тему моков. Конечно мнений много, но в той же книге Хорикова по тестированию, он склоняется больше к методу, где не нужно мокать всё, а только зависимости, которые зависят от внешней системы/меняют общее состояние

Ну контексты +- минус мне понятны, а вот что они на одни таблички ссылаться могут - не думал

истинно так, мокать всё не надо

ит депендс. иногда могут, иногда не могут, иногда могут использовать вьюхи от одной таблицы

тут, думаю, можно и на одну сделать ссылку

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

Можно, согласен.  Как вариант, почему бы и нет, спасибо. Другое дело что это немного делает разрыв, так как (хоть и мало вероятно), но чисто в теории можно товар сделать и непополаченным снова, а ивент еще не обработался, это надо как-то тоже учесть. Т.е. пока это хоть и красиво, но повышает сложность отчасти. Т.е. таких флагов уже минимум 2 - оплата заказа и статус производства.

Зато соблюдены границы контекстов, это да, плюс. Меньше выглядит как говнокод)

сложность это всё конечно повышает. Одна только инфраструктура для того чтобы ивенты надёжно летали чего стоит.
Что касается того, что заказ может стать неоплаченным - это надо отдельно разбираться почему и зачем так. Вообще заказ не может стать неоплаченным - покупатель оплатил, траназкция была. Дальше может делать отмену заказа или возврат товара - но это уже продолжение процесса или процессов, в общем тут отдельно думать надо

Есть кейс, что менеджер может увеличить стоймость заказа постфактум) зачеми  почему - хз, но есть

@knopkod4v спасибо еще раз за развернутый пример варианта решения задачи 👍

я не эксперт, но на сколько я знаю это не очень законно после оплаты менять цену

Думаю да...

Чет подзадумался. А в данном контексте, разве это бизнес правило не выходит на уровень приложения?