T>>2) имеет место быть transaction script + anemic model, где какой-то сервис всё делает за всех
T>> в применении к ддд, когда его не поняли, проскакивает и такое, как domain service
S>Я правильно понимаю, что https://hackernoon.com/making-a-case-for-domain-modeling-17cf47030732 это как раз "ддд, когда его не поняли"? Там же в DDD фигурирует domain service.

просто всегда велик соблазн сделать по привычке, поэтому народ вместо того, чтобы делать rich domain model по-кошерному, пишет процедуру, которая всё за всех делает, называя её, однако, domain service

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

получается, что наш "заказ" содержит в себе проекции этих перечисленных сущностей с необходимыми нам атрибутами,
теперь по поводу реализации: мне лично нравится идея с формулировкой правил подсчёта цены в виде fluent api, что то типа такого https://github.com/NRules/NRules/wiki/Getting-Started, https://stackoverflow.com/questions/42529694/how-to-implement-specification-pattern
т.е. "заказ" после инициализации может отсканировать имеющиеся в системе спецификации и применить к себе подходящие, на выходе получаем цену, как такая идея?

да, динамики нет, если вдруг нужно формулировать новое правило для надценки, то придётся ручками писать новую спецификацию,

я не совсем понял роль того, кто может применить к заказу произвольную скидку, это тоже надо как-то учитывать, но по идее, будет какое-то пользовательское действие\событие, на него надо будет реагировать