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

если смотреть исторически, то агрегат в ддд вообще никак не связан с какой-то там базой данных, агрегат отвечает только за поведение и валидацию тех сущностей, которые находятся под его попечительством: допустим у тебя есть заказ, цена и условия которого могут измениться в будущем, но только при наличии каких-то условий, тогда пользователь, условно говоря, отправляет команду "изменить заказ с атрибутами: номер заказа , наименование операции "потребовать 25% скидки", пользовательский номер",тогда command handler переправляет агрегату событие с упомянутыми атрибутами, агрегат берёт номер заказа, загружает себя (вовсе необязательно из реляционной базы данных) из стримового потока, производит или не производит операцию, сохраняет себя в стримовом потоке, отправляет сообщение "я изменился, новая цена : хх" , и вот уже event handler, который подписан на это событие, вытаскивает аргументы и асинхронно сохраняет информацию в реляционной или ещё какой-то там базе данных, к которой обращается клиентская часть

но можно и посмотреть, до чего народ дошёл сейчас, без event sourcing, может чего и придумали, я лет 5 уже ничего подобного не делал

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

а вот не надо упрощать и чего-то придумывать, тогда мы вообще никогда не разберёмся, есть "карта покупок", ну так пусть и будет,
теперь опять к нашим баранам: когда пользователь залогинился и увидел список товаров, то он увидел их с ценой со скидками и надбавками или эти цены появляются только тогда, когда покупатель добавил их к "карзине для покупок" ?

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

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