T>>этот "заказ" в приведённом разрезе, наверное, должен обладать методами "подсчитай цену" и "сохрани", сигнатура void, без аргументов, так как вроде всё, что нам надо для подсчётов, уже в агрегате есть, другой метод "скорректируй цену", реагирует на событие "менеджер изменил цену", аргументы тут те, которые нужны: цена или процент(непонятно что он набивает), может, userId- если это как-то протоколируется S>Спасибо. S>Пока что всё плохо. S>1. У нас в классе "заказ" есть уже две обязанности — "сохрани" и "подсчитай цену". Уже плохо. То есть тащим как бизнес-логику, так и DbContext. S>2. Опять непонятно, что за событие такое "менеджер изменил цену", и почему есть какой-то отдельный метод "скорректируй цену". Для чего это нужно? S>3. Непонятно, как работает этот агрегат с позициями заказа.
пока я ещё вроде ничего про реализацию"сохрани" не говорил: мы что используем: как ты когда-то намекал на Log / Query, т.е. Write & ReadModel, как понимаю, или обычную персистенцию в базу данных ? внутренне будет установлен флажок, что ни изменение цены (в том числе и менеджером), ни добавление или удаление позиций недопустимо, в принципе, может, стоит метод переименовать в "оформить заказ"
ты сам вроде упомянул, что если пользователь- менеджер, то он может изменить цену или я что-то не так понял?
этот агрегат может реагировать на события "добавили позицию" , "удалили позицию", ну или ,можно, наверное, эти методы добавить к агрегату напрямую
T>>внутри "подсчитай цену" будет либо отсылка к какой-то rule engine, либо, как у тебя в примере, какой-то собственный алгоритм калькуляции, вызываться этот метод будет после событий "покупатель добавил товарную позицию" или "покупатель изменил количество" S>Тут, по-видимому, неявно предполагается, что заказ у нас существует в состоянии "проект", когда его можно менять, и в состоянии "отправлен", когда фиксируются количества и цены. S>По мне так это плохая идея. Потому, что пересчитывать цены надо не только тогда, когда пользователь что-то добавил или изменил в заказе, но и при изменении списка правил. Кто какие события будет порождать, и кто на какие события будет подписываться? Мне проще вообще не иметь заказов в "предварительном" состоянии.
т.е. цена может быть изменена задним числом? чего-то я этого не понимаю, это как?
S>Тем не менее — давайте всё же посмотрим на тело "подсчитай цену" в агрегате "заказ". Все необходимые требования в топике приведены.
я исхожу из того, что агрегат обладает внутренним состоянием, которое позволяет ему рассчитать цену, не обращаясь самому к базе данных, т.е. при инициализации и изменении состояния он получает всё необходимую для расчётов информацию
T>>идея с fluent api мне нравится тем, что эти спецификации можно легко прилепить к имеющемся в цепочку; ты же в примере привёл лишь использование только одной, как ты будешь формулировать, если у тебя 3, 5, 7 формул подсчёта надценки? с if else? кроме того, сама реализация должна быть где-то в репозитарии или ты будешь DbContext тащить прямо в агрегат? S>Я вообще против агрегатов и rich модели — она даже на hello-world примерах сосёт как пылесос. S>Прелесть анемиков как раз в том, что нет мучений вроде обратных зависимостей агрегатов от DbContext. Все entity — POCO, все сервисы — stateless.
если мы ограничим агрегат только тем, что ему нужно: внутренним состоянием, никакого DbContext ему не нужно
T>>у амазона это раньше было сделано так, что для товаров, цен были свои отдельные предметные области, продукт тащился своим микросервисом, цена- своим микросервисом, композиция происходила на уровне UI (composite ui), т.е. могло теоретически быть и так, что , например, продукт сразу прогрузился, а цена- чуть позднее, ну или наоборот S>Я вам к тому, что "цена" в Амазоне — сущность эфемерная. Изменение тарифа где-то в одном углу системы не вызывает каскад миллиардов событий "скорректировать цену", как в Excel.
это я тоже не понял, что значит: "не вызывает каскадных изменений" ? если сегодня скидка на трусы на 20 %, а завтра — на всё бытовую технику, а послезавтра — на пылесосы фирмы ххх, то что значит: " без каскадных изменений"
