цена фиксируется в момент заказа

как бы да, а по другому бизнес-условию мы может ответить "Упс..."

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

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

У Ozona так сделано, цену держат какое-то время, если в корзину положил. И потом плашка типо "Видите, мы для вас цену удержали")

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

Спасибо, ушел читать про воркфлоу :)

опять же если "флоу пользователя" не звучит сложно то не стоит усложнять систему. Все эти загоны нужны там где сложностью надо управлять уже.

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

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

да, на в момент заказа цена замораживается в заказе, хотя в 1с могут сменить по согласованию с клиентом

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

Делать все события жирными не хочется, что если сделать второй вид ивента? Т.е. сущность будет выкидывать один легкий ивент (который нужен для работы системы), второй жирный историчный, его не везде нужно будет кидать... Нормальна ли сама идея кидать 2 разных ивента по одному и тому же, но с разной полнотой данных?

ну каждый ивент занимается своей работой, что тебя смущает?

наверное то что событие (не конкретный класс, а вообще) будет представлено 2мя событиями (классами грубо говоря)
как-то смутило, а не делаю ли я какую-то дичь 🤔

хотя если объект данных один, и ивент по сути один, то лучше вынеси логику или методы в отдельные сервисы

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

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

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

службы, всмысле подписчики?

исторические данные вообще в messanger передать можно, пусть в очереди сохраняются