Так уж сложилось что сейчас большинство новых серверных приложений, которые приходится видеть, дизайнятся следующим образом.
Model — тупые контейнеры данных реализующие бизнес-сущности
Service — реализация бизнес-логики, которая оперирует Model и работает с другими слоями системы в т.ч. DAL/DAO
И вроде бы все красиво и приятно. Модель часто удается протащить сквозь все уровни приложения (Persistance, Service, RCP и даже View). Service же легким движением руки можно выставить наружу как RPC или использовать другими компонентами. SOA вроде как получается?

Но вновь и вновь появляется материал сеющий зерно сомнения. Первой конечно же была статья Мартина Фаулера
AnemicDomainModel. Про то что это совсем не правильно когда логика отдельно от данных. А на резонную критику что Model нельзя связывать с внешними сервисами, например DAL. Появилась новая абстракция Repository:
http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html
http://martinfowler.com/eaaCatalog/repository.html
http://domaindrivendesign.org/books/index.html

Внимание вопрос. Кто-нибудь может внятно объяснить, или ткнуть носом чем второй подход с внедрением бесполезного слоя Repository лучше чем Anemic Model? В приведенных ссылках ни одного понятного мне объяснения не нашел. На счет упрощеного тестирования тоже не согласен, вроде и при первом подходе серьезных проблем с юнит тестами не возникало. Если кто читал книгу DDD, буду благодарен за указание главы, где можно подчерпнуть недостающее знание по интересующему вопросу.

Спасибо!