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

T>этот "заказ" в приведённом разрезе, наверное, должен обладать методами "подсчитай цену" и "сохрани", сигнатура void, без аргументов, так как вроде всё, что нам надо для подсчётов, уже в агрегате есть, другой метод "скорректируй цену", реагирует на событие "менеджер изменил цену", аргументы тут те, которые нужны: цена или процент(непонятно что он набивает), может, userId- если это как-то протоколируется
Спасибо.
Пока что всё плохо.
1. У нас в классе "заказ" есть уже две обязанности — "сохрани" и "подсчитай цену". Уже плохо. То есть тащим как бизнес-логику, так и DbContext.
2. Опять непонятно, что за событие такое "менеджер изменил цену", и почему есть какой-то отдельный метод "скорректируй цену". Для чего это нужно?
3. Непонятно, как работает этот агрегат с позициями заказа.

T>внутри "подсчитай цену" будет либо отсылка к какой-то rule engine, либо, как у тебя в примере, какой-то собственный алгоритм калькуляции, вызываться этот метод будет после событий "покупатель добавил товарную позицию" или "покупатель изменил количество"
Тут, по-видимому, неявно предполагается, что заказ у нас существует в состоянии "проект", когда его можно менять, и в состоянии "отправлен", когда фиксируются количества и цены.
По мне так это плохая идея. Потому, что пересчитывать цены надо не только тогда, когда пользователь что-то добавил или изменил в заказе, но и при изменении списка правил. Кто какие события будет порождать, и кто на какие события будет подписываться? Мне проще вообще не иметь заказов в "предварительном" состоянии.
Тем не менее — давайте всё же посмотрим на тело "подсчитай цену" в агрегате "заказ". Все необходимые требования в топике приведены.

T>идея с fluent api мне нравится тем, что эти спецификации можно легко прилепить к имеющемся в цепочку; ты же в примере привёл лишь использование только одной, как ты будешь формулировать, если у тебя 3, 5, 7 формул подсчёта надценки? с if else? кроме того, сама реализация должна быть где-то в репозитарии или ты будешь DbContext тащить прямо в агрегат?
Я вообще против агрегатов и rich модели — она даже на hello-world примерах сосёт как пылесос.
Прелесть анемиков как раз в том, что нет мучений вроде обратных зависимостей агрегатов от DbContext. Все entity — POCO, все сервисы — stateless.

T>у амазона это раньше было сделано так, что для товаров, цен были свои отдельные предметные области, продукт тащился своим микросервисом, цена- своим микросервисом, композиция происходила на уровне UI (composite ui), т.е. могло теоретически быть и так, что , например, продукт сразу прогрузился, а цена- чуть позднее, ну или наоборот
Я вам к тому, что "цена" в Амазоне — сущность эфемерная. Изменение тарифа где-то в одном углу системы не вызывает каскад миллиардов событий "скорректировать цену", как в Excel.