Будем спорить с Мартином Фаулером и начнем с конца его стать, в которой он говорит:
Я не знаю, почему этот анти-шаблон так распространен.
Коротко он поясняет:
По сути, проблема анемичных моделей предметной области заключается в том, что они несут все затраты модели предметной области, не принося никаких преимуществ.
Мартин прав если язык поддерживает строго-типизированные структуры (коими являются объекты классов во многих языках), но если нет (а такие языки есть), то тут строгие проверки гетеров/сетеров очень помогают. Еще, бывают случаи, когда язык не позволяет создавать имутабельные объекты (а ведь разработчик часто желает быть уверен, что где-то по пути объект не изменится, и в этот момент помогает приватные поля + гетеры). Поехали дальше:
Основная цена — это неуклюжесть сопоставления с базой данных, что обычно приводит к созданию целого уровня сопоставления O/R.
В мире уже давно существуют инструменты маппинга данных (ORM/AcriveRecord), т.е. речи о создания нет, но вот о использовании и осваивания, да.
Это полезно, если вы используете мощные методы объектно-ориентированного программирования для организации сложной логики. Однако, перенося все поведение в службы, вы, по сути, получаете сценарии транзакций и, таким образом, теряете преимущества, которые может дать модель предметной области.
Парадоксально глупо в доменную модель инъектить другие доменные модели, классы-сервисы помогающие взаимодействовать с сторонними службами, вспомогательные классы, и т.д. Видимо поэтому Фаулер в своем труде ниже цитирует Эрика Эванса, который говорит, что логику взаимодействия нужно выносить в прикладной уровень (Application Layer/Service Layer). Однако Фаулер ниже пишет:
Ключевым моментом здесь является то, что сервисный уровень тонкий — вся ключевая логика лежит на доменном уровне.
Хорошо, но где же тогда например писать проверку бизнес условия, в результате которой Service-класс будет выполнять различную работу с данными, и тут мы понимаем, что проверка все равно останется в Service-классе, а значит в доменные модели предлагается выносить более сложные бизнес-проверки.
В итоге, Фаулер не прав, что Anemic Model это антипаттерн и выше обозначены причины.