Anemic vs Rich entities: нечестная дилемма

[DimNS]

Вроде звучит логично, а потом снова приходим к тому что бизнес таки попросит расчет скидки в CartOrder и BackofficeOrder, а ведь это сразу затронет еще и оба repo чтобы сохранить новую скидку в базе и вот у нас уже или дублирование расчета скидки в двух местах, либо расчет один где-то в некоем сервисе, а каждый *Order использует это, чтобы в будущем не случилось так что в разных местах скидка считается по разному

И так далее и тому подобное

[DenisYu-1]

а потом снова приходим к тому что бизнес таки попросит расчет скидки в CartOrder и BackofficeOrder

От этого не уйдёшь, это да :)

Но ситуация как будто обычная – как убрать дублирование кода и где должна жить логика. Трейты или сервисы или что угодно – вопрос рефакторинга и договорённостей.

Я бы даже сказал, что тут проблема дублирования и смешивания доменов будет заметнее, чем в случае с единой сущностью и тут и там.

[Reposlav]

Со всем уважением к старику Фаулеру, но ООП, которое формировалось в 70-х, и то "ООП", которое мы практикуем сегодня, — довольно разные вещи. Современные best practices могут противоречить даже тому, что когда-то считалось фундаментальными принципами ООП. Например, наследование раньше было одним из центральных механизмов, а сегодня рассматривается скорее как ситуативный инструмент, зачастую уступающий композиции.

Выражение "процедурный код в объектной обёртке" само по себе ничего не говорит о качестве архитектурного решения.

Лично я разделяю бизнес-логику и логику управления состоянием. Последняя вполне может находиться внутри модели, даже если бизнес-правила вынесены в сервисы. И я не вижу, почему такой подход должен считаться архитектурным недостатком только потому, что он не соответствует классическим представлениям об ООП