Вы видимо не особо понимаете что такое 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). Насчет сходства смотрите топик выше.

2 NotGonnaGetUs:
авторВы даёте совершенно иную трактовку терминам.
уважаемый, читайте плиз топики внимательней. В каком месте я давал терминам иную трактовку?
авторDomain Model, Transaction script - это способы представления бизнес логики.
DataMapper (ORM) ,Active Record, etc - способы взаимодействия с источниками данных.
А где вы видели что я трактовал это иначе?
авторВы путаете термины.
Я ничего не путаю, вы просто недостаточно хорошо знает что такое Domain Model, либо не совсем понимаете то что читаете.

авторХотя бы тут:
"Сходство с Facade в том что Domain Model позволяет работать Application Model (иногда используется просто термин Model) с Domain Objects не напрямую а а через так называемую Administrative Object (иногда используется термин Orchestrating Object)."Ну и какие тут термины я трактовал иначе? Или хотите сказать DM работает по другому? Или Facade работает по другому?
авторОткройте книжку, прочитайте что пишет Фаулер. Я не сомневаюсь, что термин Domain Model используется ещё в 256 значениях у других авторов.
Вы из пальца домыслы не высасывайте, а разберитесь что всетаки есть DM. Потому как не может быть ни 256 ни даже 2 разных DM(ответвления/дополнения в виде MVC, Model 2 и др не в счет конечно). Тот же Фаулер, исходя из приведенных отрывках, говорит о том же самом. Проблема в том что вы это не понимаете.

авторБог мой. Вы судите о том, что я понимаю и что не понию по кем-то цитируемым отрывкам из Фаулера? Это, право, не серьёзно.
Я и не сужу о ваших знаниях по чьим то высказываниям. Имелись ввиду высказывания о том что имел ввиду Фаулер говоря о DM. О вашем незнании DM я сужу по другим факторам.
Ладно, будем конструктивнее.
Начнем с того что такое DM(я сорри заранее если, где то будет не совсем понятно. у меня в голове термины на инглиш, которые я буду все равно указывать для аутентичности:)).
DM это тип архитектуры которая предусматривает описание бизнес проблемы (problem domain) и позволяет отделить решение бизнес проблемы от пользовательского интерфейса (UI).
К примеру бизнес проблема заключается в моделировании работы госпиталя. В этом случае DM будет содержать классы абстракционирующие пациентов, палаты, докторов, лекарства и другие статические своийства включая ассоциации(structural model).
Естественно будут и динамические своийства, т.е протоколы классов и из взаимодействие (dynamic model). Все это называется domain objects и соответственно находится внутри DM. Это в принципе тоже о чем и говорит Фаулер и то же что упоминаете вы:
автор"Типовое решение domain model предусматривает создание сети взаимодействующих обхектов, каждый из которых представляет некую осмысленную сущность - либо такую крупную, как промышленная корпорация, либо настолько мелкую, как строка формы заказа."
Второй аскпект DM, как уже было написано выще заклучается в отделении бизнес модели (называйте это бизнес логикой если хотите) от UI. Причина в переносимости (portability), поддержке (maintenance) и тд. Все это формирует золотое правило планирования систем (system architecture) что DM и UI всегда должны быть отделены друг от друга.
Этот аспект поднимает вопрос о том что между DM и UI должен быть некий слой который будет адаптировать DM к разным (а может быть и нескольким паралельно используемым) UI. Этот слой называется application model(упоминался в предидущих топиках) и является мостом между DM (business tier) и UI (presentation tier).
Теперь самое (или почти самое) интересное. Мы знаем что в нашей DM существует множествое обьектов связанных ассоциациаями. Но мы также знаем что обьекты взаимодействуют друг с другом и мы также знаем что несмотря на взаимодействия обьекты не должны быть связаны между собой (имеется в виду loose coupling). Плюс к этому, мы должны принять во внимание и тот факт что application model тоже должна взаимодействовать с обьектами внутри DM (domain objects). Эти проблемы решаются путем создания administrative object (orchestrating object) внутри DM. Другими словами, обьекты внутри DM будут общаться друг с другом не напрямую а через admin object. Аналогично application model будет работать с DM через admin object. Здесь на самом деле отлично видны как минимум два design pattern - mediator и facade. Причем оба они имплементируются всего лишь одним обьектом - admin object. Красиво, а?
Теперь об ORM (я не стал все смешивать в кучу сначала для ясности). Есть несколько вариантов подклучения ORM компонентов к подобной системе. Имхо самый красивый это включение ORM компонента внутрь admin object (по ходу design pattern используемая в данном случае - Composite). Описание взаимодействия admin object с ORM компонентом опускаю, это отдельная тема, очень интересная кстати.
Ну и что здесь (имеется в виду описание DM) не совпадает с Фаулером?
Если вам это интересно и хотите узнать больше (но не можете найти в сети), то могу найти и отправить вам выдержки из университетских пособий (все на инглиш) где все разжевано по буквам.

2 expp:
автормоё мнение такое: OU не прав разделяя Architecture patterns и Design patterns, и скрещивая Facade и Domain Model. Не прав на столько, что доказывать обратное по-моему просто бесполезно. Вы хотя бы с определений из одного контекста начните, напишите "Architecture patterns" это ... "Design patterns" это ... и т.д. Вот найдите и процитируйте и укажите источник. А то вы помоему свои какие то сентенции излагаете...
Да писал уже, что еще один раз написать, или вы вернетесь и прочтете внимательно?
такие вещи в универах учат, типа дважды два и если вы думаете что architectural patterns и design patterns это одно и тоже то дело ваще конечно...
автори скрещивая Facade и Domain ModelА кто их скрещивает? Facade (как вариант) используется для имплементации DM, куда еще проще то?

еще раз, где написано что DM выполняет роль Facade?

авторОна может скрываться за фасадом, но никак не являтся имтак вам же и говорят, что взаимодействие с (и внутри) DM происходит через admin object. Вот где facade!

2 notgonnagetus:
сорри за то что не пояснил сходство дословно с вашим предложением. По ходу всего топика было ясно что к чему, тем более тому кто знает что такое DM. Относительно application model, то если вы хотите сравнить ее по аналогии с design patterns то это будет adapter или decorator но никак не facade. Опять же никто и не говорил что MVC описывает бизнес логику. Имелась ввиду архитектура MVC vs архитектура использующая DM (+ application model, ui).

2 funikovuri:
авторВы имели в виду что нужно указанный admin object и ORM-средство моделировать при помощи древовидной иерахии?Не обязательно сложные структуры. Возьмите как примитивный вариант instance variable (типа construction by composition)
авторИ еще, у вас судя по всему представление о доменам больше всего соответсвующее реализации идеи в j2ee и entity beans (вы говорили еще про smalltalk, но я с ним не знаком). Так вот идея вообще-то претерпела длительно развитие и сейчас уже может отличаться от той что была когда-то применена в smalltalk (я это утверждать не могу но сложилось именно такое впечатление).
в чем идея принципиально изменилась? что бизнес логика исчезла? ORM средства поменялись конечно в связи с persistence beans которые можно использовать вместо hibernate (ЕЕ 5). Плюс куча других вещей, но не фундаментальных.

2 funikovuri:
авторя всегда думал что instance variable это просто instance variable.
сорри (уже запарился писать на самом деле:)). имелся ввиду примитивный вариант construction by composition, т.е включение ORM компонента внутрь admin object как instance variable.
авторИдея на самом деле действительно сильно изменилась и основной крен тут в сторону дальнейшей специализации доменов как легкой сущности, описывающей структуру и "собственную бизнес логику" (по сути некоторые ограничения целостности) тогда как именно бизнес логика переноситься в отдельные классы инкапсулирующие reusable unit-of-work components
ничего нового в этом подходе нет на самом деле, если я вас правильно понял. Вас ведь не заставляли/заставляют использовать только один подход (3-tier к примеру).