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

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

велик соблазн выделить оперaцию чтения и , соответственно, калькуляции в отдельную операцию типа чего-то такого: http://www.codinginstinct.com/2011/04/queries-aggregates-ddd.html, но всё-таки ценообразование — , поэтому надо ещё посмотреть, куда это относится

вот само управление скидками-надценками интереснее. как это сейчас реализовано? как эта информация сохраняется? т.е. это было бы реальной задачей агрегата