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 к примеру).