Здравствуйте, takTak, Вы писали:

T>ну, переименуй это "сохрани" в "создать заказ" или "оформить заказ" — не знаю, как там у вас что в UI называется
Ок, переименовал. В любом случае, тот "оформить заказ", который я себе представляю, требует наличия dbContext.
Как без него обойдётся агрегат в DDD —

T>если создание заказа- это размещение заказа, т.е. placeOrder, то что тогда такое "отправить заказ" ? Вот это я вообще не понимаю: "Если мы подготовили его в январе, а потом пришёл новый прайслист, и мы отправили заказ уже в феврале", кто его подготовил?
Ну, так это я пытаюсь догадаться, как работает предлагаемая вами архитектура. Из того, что есть какие-то события типа "пользователь изменил цену", или методы "добавить позицию", я понимаю, что агрегат "заказ" у вас обретает существование ещё до того, как будет "сохранён", или "отправлен" — в общем, до того, как начнётся собственно выполнение заказа.
В обычных интернет-магазинах такие штуки называются чем-то типа "cart" — типа я интерактивно складываю и вынимаю товары из корзинки; а потом, когда я уже готов на выход, корзинка превращается в заказ при помощи операции checkout.
Я не хотел усложнять задачу, т.к. у нас тогда появляется ещё два агрегата (корзина и "элемент корзины"), и мы рискуем вообще не закончить
Поэтому условимся считать, что никакой корзинки нету, и заказ, как таковой, возникает только в момент нажатия на кнопку "заказать". А аналог корзинки у нас эфемерен, существует только в воображении клиента, и нас не интересует.
Ну, типа там какой-то джаваскрипт, интересоваться которым — не барское дело. Наше дело — выставить API для веб-клиента; и с точки зрения этого API до момента "заказать" заказа не существует, а после этого момента изменить уже ничего нельзя.

T>нужны ли для калькуляции какие-то вызовы в базу данных или я могу загрузить все интересующие меня аргументы при создании агрегата?
Ну, это же вы архитектор. Я играю роль заказчика; диктовать вам, когда лазить в базу, я в этой роли не готов. Бизнес-требования я вам задал; если они непонятны — спрашивайте.
А как технический специалист я как раз и хочу понять, что такое этот DDD, и насколько ужасные получаюстя решения при его применении.

T>так когда происходит перебор правил, в системе может появиться изменение, типа сегодня все трусы снова на 5% дороже, ты хочешь сказать что амазон ждёт следующего дня, чтобы скомпилировать правила и перезапустить сервер?
Я не знаю точно, но думаю, что нет. Решительно непонятно, зачем перекомпилировать какие-то правила и перезапускать сервер, когда можно просто добавить новое правило в табличку правил, и оно начнёт учитываться ровно с момента его effectiveStartDate. Давайте закроем тему амазона, чтобы не отвлекаться.

T>и ещё: покупатель просто каталога всех товаров не видит, он всегда выбирает вначале продавца, и только потом- товары?
Да, для упрощения понимания можно предположить, что у каждого продавца — свой "магазин". www.resellerA.com, www.resellerB.com.
Покупатель заходит в какой-то из этих магазинов, и видит ту версию каталога, которую мы отдаём соответствующему магазину (продавцу, reseller в родной номенклатуре).
С точки зрения покупателя не существует такой штуки, как "каталог всех товаров", есть только "каталог товаров у продавца resellerA".