Если не усложнять, то в комментарий к заказу записать все модификаторы или в json

Ok.
Рассчет цены - это кросс-граничная операция (пересекает несколько контекстов — лояльность, пользователь, история заказаов). Поэтому, если использовать Заказ как Агрегат, то модификаторам цены в нем не место (ему ведь в сущности только конечная цена интересна и совершенно не важно, как она расчитывалась).

Для такой логики можем использовать Domain Service, логика его работы примерно такая:

OrderService //stateless-сервис
void placeOrder(orderId, itemId, qty) {
  //определение стоимости элемента в заказе с учетом модификаторов
  //
  order.place(item, price); //это может быть удаленный вызов другого сервиса на уровне реализации
}

Но то, что заказ не может быть изменен, наводит на мысль, что Заказ - это Value Object. Если у него совершенно нет никакого жиненного цикла, он не может быть изменен, то это упростит реалзиацию. Советую подумать об этом 🙂


Для чего я задавал вопросы:
>> Стоимость расчитывется всегда в контексте отдельного элемента заказа или элементы могут оказывать взаимное влияние на конечную цену (например - три товара в заказе - скидка 10%, четыре - 15%, общая сумма заказа больше 10.000, значит скидка на заказ 5% и так далее)?

Чтобы определить, является ли расчет цены частью инварианта Заказа, ответ - нет, так как состав заказ в контексте заказа на цену не влияет.

>> Если заказ уже создан и не изменяется, может ли динамически измениться цена? (например, скидка для города изменилась с 5% до 10%)
>> В какой момент цена фиксируется? В момент оплаты?

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

———————
Если нужна история примененный акций, это может быть решено обычным логированием последовательности примененных акций в момент рассчета цены, вроде Discount (orderId, discountId, discountType, discount, dateApplied, ….)

Да, спасибо. Думал про json но мне показалось, что в будущем это может некоторые проблемы создать, когда придется например вручную что-то модифицировать. Добавлять/убирать акции, чтобы это влияло на заказ. Но это видимо возврат к "управлению заказом"

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

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

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

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

Ok.
Рассчет цены - это кросс-граничная операция (пересекает несколько контекстов — лояльность, пользователь, история заказаов). Поэтому, если использовать Заказ как Агрегат, то модификаторам цены в нем не место (ему ведь в сущности только конечная цена интересна и совершенно не важно, как она расчитывалась).

Для такой логики можем использовать Domain Service, логика его работы примерно такая:

OrderService //stateless-сервис
void placeOrder(orderId, itemId, qty) {
  //определение стоимости элемента в заказе с учетом модификаторов
  //
  order.place(item, price); //это может быть удаленный вызов другого сервиса на уровне реализации
}

Но то, что заказ не может быть изменен, наводит на мысль, что Заказ - это Value Object. Если у него совершенно нет никакого жиненного цикла, он не может быть изменен, то это упростит реалзиацию. Советую подумать об этом 🙂


Для чего я задавал вопросы:
>> Стоимость расчитывется всегда в контексте отдельного элемента заказа или элементы могут оказывать взаимное влияние на конечную цену (например - три товара в заказе - скидка 10%, четыре - 15%, общая сумма заказа больше 10.000, значит скидка на заказ 5% и так далее)?

Чтобы определить, является ли расчет цены частью инварианта Заказа, ответ - нет, так как состав заказ в контексте заказа на цену не влияет.

>> Если заказ уже создан и не изменяется, может ли динамически измениться цена? (например, скидка для города изменилась с 5% до 10%)
>> В какой момент цена фиксируется? В момент оплаты?

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

———————
Если нужна история примененный акций, это может быть решено обычным логированием последовательности примененных акций в момент рассчета цены, вроде Discount (orderId, discountId, discountType, discount, dateApplied, ….)

А в каком контентсте тогда будут модификаторы цены если не в заказе? Ведь цена находится в заказе, почему бы и модификаторам не быть там?

Основной вопрос заучит так: стоит ли впускать в модель предметной области работы с заказом элементы предметных областей акций, мест доставки, статусов пользователей и тем самым создавать достаточно сильную зависимость между всеми этими контекстами.

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

Да, кажется понял. Нет, вопрос немного не об этом.

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

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

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

Такая ситуация. У тебя модификатор применен типа за 3 штуки одной позиции минус 10 процентов. В заказе убирают одну штуку. Что происходит?

Ну ничего не изменилось

Изменили на 45 штук

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