T>>пока я ещё вроде ничего про реализацию"сохрани" не говорил: мы что используем: как ты когда-то намекал на Log / Query, т.е. Write & ReadModel, как понимаю, или обычную персистенцию в базу данных ?
S>Я потерял нить. Вот цитата из вашего ответа:
S>

S>тот "заказ" в приведённом разрезе, наверное, должен обладать методами "подсчитай цену" и "сохрани"

ну, переименуй это "сохрани" в "создать заказ" или "оформить заказ" — не знаю, как там у вас что в UI называется


T>>т.е. цена может быть изменена задним числом? чего-то я этого не понимаю, это как?
S>Как раз не может. После PlaceOrder никакого изменения цены не может быть. До PlaceOrder не существует никакого Order. Если бы мы сохранили Order в состоянии "предварительный", то в нём нельзя фиксировать цену — датой заказа считается та, когда он "отправлен". Если мы подготовили его в январе, а потом пришёл новый прайслист, и мы отправили заказ уже в феврале, то оплачивать придётся по ценам февраля.

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

T>>я исхожу из того, что агрегат обладает внутренним состоянием, которое позволяет ему рассчитать цену, не обращаясь самому к базе данных, т.е. при инициализации и изменении состояния он получает всё необходимую для расчётов информацию
S>Вот этого я и не понимаю. Хочу увидеть пример кода. Потом можно будет попытаться понять, откуда агрегат будет брать это внутреннее состояние.
T>>если мы ограничим агрегат только тем, что ему нужно: внутренним состоянием, никакого DbContext ему не нужно
S>Вот как раз тут важны детали.
нужны ли для калькуляции какие-то вызовы в базу данных или я могу загрузить все интересующие меня аргументы при создании агрегата?

T>> это я тоже не понял, что значит: "не вызывает каскадных изменений" ? если сегодня скидка на трусы на 20 %, а завтра — на всё бытовую технику, а послезавтра — на пылесосы фирмы ххх, то что значит: " без каскадных изменений"
S>Это значит, что нет никаких "событий" и "подписок". Есть просто метод getPrice(goodId, customerId), который вызывается при загрузке страницы. Где-то у него внутри перебираются pricing Rules, которые матчат товар и кастомера; применяются всякие комбинации. Результат отправляется клиенту и навсегда забывается. Плюс-минус кэширование.
так когда происходит перебор правил, в системе может появиться изменение, типа сегодня все трусы снова на 5% дороже, ты хочешь сказать что амазон ждёт следующего дня, чтобы скомпилировать правила и перезапустить сервер?

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