Size: a a a

Software Design/Architecture/Zen

2021 January 10

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Какая вероятность что у вас это изменится и заказ сможет содержать 1 to n позиции?
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Dmitriy Tkachenko
Какая вероятность что у вас это изменится и заказ сможет содержать 1 to n позиции?
Около 0вая. Сейчас вроде даже нет такого функцонала.  Это больше рассчет вдруг заказчик захочет.
источник

SB

Sergey Baranov in Software Design/Architecture/Zen
Павел Г.
Да, кажется понял. Нет, вопрос немного не об этом.

Как у меня сейчас реализовано:
Есть заказ, есть некие "стратегии по модификации цены".  Они пробегают по заказу и меняют его цену. Т.е. это акции и прочее.   Грубо говоря ваш OrderService который вы предлагали.

Но с этим функионалом у меня:
1) Нет истории - ну это ладно
2) Я не могу кусками модифицировать заказ. Т.е. например забрать у заказа акцию или добавить ее вручную.

Поэтому я описал свою идею: записывать к заказу "модификаторы цены" - т.е. те изменения которые были применены к цене.  Их можно было бы убрать/добавлять вручную. Вроде похоже на "историю" а вроде это и не история. Поэтому я зазвал это "модификатор цены". Т.е. это не функционал по изменению, а фактические результаты "стратегии по модификации цены" .
Очень плохо с неймингом и терминологией, сори, плохо объясняю :(
Про ручное применение акций в изначальной постановке не было :) В изначальное постановке было про низменность цены :)

Тогда можно развить идею в том, что «Действующая Акция»  и «Примененная к определенному заказу акция в определенное время» - это две разные вещи в разных контекстах. Примененные акции будут жить в Агрегате заказ и через заказ их можно модифицировать.

Заказ будет обеспечивать инвариант товара и акций (например - суммарная скидка по всем акциям не больше 50%)

Если именно заказ за этим следит, конечно.
источник

А

Алексей in Software Design/Architecture/Zen
Павел Г.
Да, кажется понял. Нет, вопрос немного не об этом.

Как у меня сейчас реализовано:
Есть заказ, есть некие "стратегии по модификации цены".  Они пробегают по заказу и меняют его цену. Т.е. это акции и прочее.   Грубо говоря ваш OrderService который вы предлагали.

Но с этим функионалом у меня:
1) Нет истории - ну это ладно
2) Я не могу кусками модифицировать заказ. Т.е. например забрать у заказа акцию или добавить ее вручную.

Поэтому я описал свою идею: записывать к заказу "модификаторы цены" - т.е. те изменения которые были применены к цене.  Их можно было бы убрать/добавлять вручную. Вроде похоже на "историю" а вроде это и не история. Поэтому я зазвал это "модификатор цены". Т.е. это не функционал по изменению, а фактические результаты "стратегии по модификации цены" .
Очень плохо с неймингом и терминологией, сори, плохо объясняю :(
Хорошая идея, только ещё стоит учитывать "порядок" этих модификаторов
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Sergey Baranov
Про ручное применение акций в изначальной постановке не было :) В изначальное постановке было про низменность цены :)

Тогда можно развить идею в том, что «Действующая Акция»  и «Примененная к определенному заказу акция в определенное время» - это две разные вещи в разных контекстах. Примененные акции будут жить в Агрегате заказ и через заказ их можно модифицировать.

Заказ будет обеспечивать инвариант товара и акций (например - суммарная скидка по всем акциям не больше 50%)

Если именно заказ за этим следит, конечно.
Да, вот именно про это я сзначлаьно говорил. Что есть куча разных отдельных контекстов с своими данными, которые могут создавать "Примененная к определенному заказу акция в определенное время" . Я это назвал "модификатор цены".
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Sergey Baranov
Про ручное применение акций в изначальной постановке не было :) В изначальное постановке было про низменность цены :)

Тогда можно развить идею в том, что «Действующая Акция»  и «Примененная к определенному заказу акция в определенное время» - это две разные вещи в разных контекстах. Примененные акции будут жить в Агрегате заказ и через заказ их можно модифицировать.

Заказ будет обеспечивать инвариант товара и акций (например - суммарная скидка по всем акциям не больше 50%)

Если именно заказ за этим следит, конечно.
Мы разместили заказ, к нему применился модификатор. Мы пошли получать инвойс, а эта акция завершилась. Что делать?
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Sergey Baranov
Про ручное применение акций в изначальной постановке не было :) В изначальное постановке было про низменность цены :)

Тогда можно развить идею в том, что «Действующая Акция»  и «Примененная к определенному заказу акция в определенное время» - это две разные вещи в разных контекстах. Примененные акции будут жить в Агрегате заказ и через заказ их можно модифицировать.

Заказ будет обеспечивать инвариант товара и акций (например - суммарная скидка по всем акциям не больше 50%)

Если именно заказ за этим следит, конечно.
Спасибо за развернутые ответы! Как я понял, примерно в правильном направлении думаю.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Dmitriy Tkachenko
Мы разместили заказ, к нему применился модификатор. Мы пошли получать инвойс, а эта акция завершилась. Что делать?
Модификаторы на момент создания заказа. Хотя тут можно усложнить, делать перерасчет после оплаты и показывать разницу.
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Изменится ли заказ в этом случае? Конечно нет, но тк модификатор в заказе, он будет изменен
источник

А

Алексей in Software Design/Architecture/Zen
Dmitriy Tkachenko
Мы разместили заказ, к нему применился модификатор. Мы пошли получать инвойс, а эта акция завершилась. Что делать?
Акция то уже примелась, как она может закончится? 🌚
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Dmitriy Tkachenko
Изменится ли заказ в этом случае? Конечно нет, но тк модификатор в заказе, он будет изменен
Модификатор не будет изменен - он отдельный к каждому заказу
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Я видимо запутал термином "модификатор"
источник

А

Алексей in Software Design/Architecture/Zen
Павел Г.
Модификаторы на момент создания заказа. Хотя тут можно усложнить, делать перерасчет после оплаты и показывать разницу.
Ну такое, я вижу товар, оплачиваю и мне там потом что то пересчитывают?
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Алексей
Ну такое, я вижу товар, оплачиваю и мне там потом что то пересчитывают?
Ну тут можно кейс ввести - согласы ли вы с изменениями и т.д. А не по факту пользователя вводить в ситуацию и переплату.
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Но опять таки - это редкий кейс, сейчас он даже не задумывается, его Дмитрий предложил :)
источник

А

Алексей in Software Design/Architecture/Zen
Павел Г.
Я видимо запутал термином "модификатор"
В опенкарте такая система 🌚
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Между размещением заказа и формированием инвойса есть промежуток. Значит может получиться ситуация, когда инвойс будет выдан на невалидный заказ, не?
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Я дилетант полный в этой области, но интересно)
источник

А

Алексей in Software Design/Architecture/Zen
Dmitriy Tkachenko
Между размещением заказа и формированием инвойса есть промежуток. Значит может получиться ситуация, когда инвойс будет выдан на невалидный заказ, не?
Какой промежуток времени и почему?
источник

ПГ

Павел Г. in Software Design/Architecture/Zen
Dmitriy Tkachenko
Между размещением заказа и формированием инвойса есть промежуток. Значит может получиться ситуация, когда инвойс будет выдан на невалидный заказ, не?
Почему он невалидный? Он ок. Я сам дилетант)
источник