B>Но вновь и вновь появляется материал сеющий зерно сомнения. Первой конечно же была статья Мартина Фаулера
B>AnemicDomainModel. Про то что это совсем не правильно когда логика отдельно от данных. А на резонную критику что Model нельзя связывать с внешними сервисами, например DAL. Появилась новая абстракция Repository

Не знаю, как насчет новой... Repository был описан в книжке Фаулера по архитектуре в 2003 г.
"Anemic Domain" Фаулер ругает потому, что логика, природно связанная с бизнес-объектами, выносится куда-то еще, как следствие — повторяется, и получается что-то близкое к процедурному подходу (можете назвать это SOA, легче не станет).

Если вы разделите бизнес-логику на логику домена и логику приложения, то станет видно, что первая — да, должна быть внутри, а вот вторая может быть и выставлена как сервис.

DAL — это не совсем внешний сервис, это скорее "внутренний сервис", он ближе к данным и, в принципе с ним могут работать и сами бизнес-объекты. Впрочем, тут есть разные подходы.

Repository — тот, вроде, вообще ортогонален проблеме Anemic Domain — он может применяться как в anemic domain, так и в rich domain. Он позволяет бизнес-логике формулировать "объектные запросы", запросы на выборку бизнес-объектов определенного типа по структурированно заданным критериям. За счет этого связь между DAL и бизнес-логикой становится не такой жесткой, развязывается через Repository.
Очевидный минус — Repository сложно сделать одинаково эффективным для любых выборок. Ручной SQL все равно будет гибче и мощнее и быстрее.

Все вышесказанное — довольно IMHO