Вы видимо не особо понимаете что такое Domain Model и в чем смысл данного типа архитектуры. Кстати между Domain Model и средствами ORM связи нет абсолютно никакой, если не хотите использовать Domain Model используйте архитектуру типа клиент сервер (при этом не забываем 7 отмерить прежде чем 1 раз испортить :)).
Про средства ORM вам тоже нужно почитать побольше чтобы знать как минимум их типы и что они из себя представляют.

авторDomain model - способ организации слоя бизнес логики, т.е. понятие дважды "логическое", во-первых потому, что это pattern...Domain Model это тип архитектуры, а не design pattern (для интересующихся, design pattern с аналогичными свойствами/функциями называется Facade). Вообще Domain Model появилась в Smalltalk еще лет 30 тому назад, равно как и основные design patterns (но о них сейчас речь не идет). В дальнейшем этот тип архитектуры перекачевал в другие технологии/языки и получил развитие в виде MVC и тд.
авторORM это если хотите библиотека отображающая друг на друга структуры.
ORM это mapping между реляционной и обьектно ориентированной парадигмами. Цель ORM - обеспечение data persistence между ОО системой и RDMBS.
авторпросто все они тесно связаны guideline'ами и поэтому переплетаются в мозгах
В принципе Domain Model и средства ORM никак не связаны (если вашей системе не нужен data persistence, то соответсвенно нет нужды и в ORM средствах). С другой стороны, большинство систем требуют data persistence. В этом случае есть два варианта, либо использовать средства ORM(Hibernate, Top Link и др), либо другие решения типа adapters, data sets и tables (стандартный набор .Net компонентов). Последний вариант не является ни ОО, ни ORM подходом, хотя и может быть использован в Domain Model/MVC/Business Logic.
автортут рецепт один - практика. пяти табличное приложение действительно быстрее накидать на recordset'ах (и .Net рулит)...Не рулит здесь то что предлагает .Net, даже для 5 таблиц. При всех подходах (от RDBMS к ОО системе или наоборот) дело не в числе таблиц (которое диктуется условиями data persistence) а в сложности классов. А обеспечить data persistence сложных классов с помощью .Net средств (adapters, data sets, etc) ооочень сложно и криво (хотя есть и плюс в использовании хранимых процедур на стороне сервера). Отсюда и мнение о том что этот подход не вяжется с ООП (в сети куча статей).
В свое время у меня был свое ORM решение которое давольно таки нормально работало/работает в нескольких системах. Сейчас в сети существует аналогичный проект Amber (для ORM mapping я использовал abstract factories, так как annotations в java тогда еще не было, да и архитектура оставалась общей для обоих c# и java).

Относительно вживления ORM средств в 3,4 системы интересного мало, в любом случае это всего лишь один из компонентов.

авторDomain Model это тип архитектуры, а не design pattern (для интересующихся, design pattern с аналогичными свойствами/функциями называется Facade).
авторФасад? У Мартина Фаулера DomainModel это вовсе не фасад. Это модель предметной области отражённая ввиде классов, подразумевающая использование таких вещей наследование и всяких разных паттернов.а где вы в приведенной фразе видите утверждение что Domain Model это Facade? как раз наоборот, говорится что Domain Model это не design pattern, просто еще существует (независимо от Domain Model) design pattern называемый Facade который имеет аналогичные свойства/функции.

авторВ чём аналогичные, что такое скрывает от общественности domain model?
Таблички в базе данных? Так этим занимает ORM, а не модель.
А при чем тут таблицы и ORM компоненты? Вы почему то смотрите на Domain Model исключительно в контексте работы с ORM. Хотя это разные вещи, причем не обязательно связаные между собой (ORM средства могут использоватся как компонент Domain Model, а могут и не использоваться. Выше об этом уже говорилось).
Сходство с Facade в том что Domain Model позволяет работать Application Model (иногда используется просто термин Model) с Domain Objects не напрямую а а через так называемую Administrative Object (иногда используется термин Orchestrating Object).

2 expp:
авторЯ думаю, может быть вы (OU) под шаблоном (перевод оспаривается) понимаете GoF. Но у них не enterp app, а у Фаулера они самые
Совершенно верно. Architecture patterns относятся к дизайну/взаимодействию системы/компонентов системы, Design patterns относятся дизайну/взаимодействию классов.
авторRemote Facade - огрублённый (coarse grained) интерфейс для клиентов для удалённого обращения...
Вы здесь немного путаете Architecture patterns с Design patterns, а речь шла о сходстве некоторых свойств Domain Model и Facade (Design pattern). Насчет сходства смотрите топик выше.