Здравствуйте, takTak, Вы писали:
T>есть же, наверное, какая-то история заказов или сделок? кроме того, цену на "заказ" или "корзину покупок" вроде как менеджер тоже изменить может, т.е какая-то сущность этому соответствует?
История — конечно есть. Но её реализация делается примерно одинаково примерно везде.
По поводу цены — ещё раз расскажу всё то же самое: менеджер "меняет" цену прямо в UI. Вот он получил список товаров с рекомендованными ценами, отобрал некоторые из них, цену переопределил — отправил заказ.
Всё. До "отправки заказа" никакого заказа нет. Даже управление в наш код не попало ещё. Нет никаких событий, и никаких подписчиков у этих событий.
S>>Пользователь сразу видит список товаров с их ценами. Скидки/надбавки ему не видны — это закрытые подробности. Всё, что он видит — конкретную сумму.
T>ну раз так, то тогда попытки прилепить логику подсчёта цены к "заказу" были неправильными, "заказ" отвечает лишь за подсчёт конечной цены, ну ещё и эта коррекция цены менеджером тоже где-то должна произойти
Ну, вот ждём ответа от DDD — где же будет вся эта логика. И где будут храниться сами параметры ценообразования.

T>а по самой проблеме подсчёта цен: да, у ддд есть проблемы, когда для выполнения каких-то операций нужно преодолевать границы предметной области или агрегатов, мне на ум приходят две попытки, как подобные проблемы можно разрешить:
T>1) либо денормализацией данных, так что каждый агрегат или предметная область получает в виде копии всю необходимую информацию (обычно путём подписки и отправки сообщений)
T>2) либо композицией логик разных предметных областей

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