S>Это предполагает наличие изменяемой сущности "заказ". Как мы уже неоднократно обсудили в этом топике, в рамках нашей задачи такой штуки нет.

есть же, наверное, какая-то история заказов или сделок? кроме того, цену на "заказ" или "корзину покупок" вроде как менеджер тоже изменить может, т.е какая-то сущность этому соответствует?

S>Пользователь сразу видит список товаров с их ценами. Скидки/надбавки ему не видны — это закрытые подробности. Всё, что он видит — конкретную сумму.

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

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

первый путь , в принципе, легко реализуем, когда есть инфраструктура для обработки сообщений и всё решение сделано в ддд-стиле,
но я подумаю на досуге о второй возможности