Что-то слишком уж разнятся понимания что же такое Толстая архитектура, а что такое стройная архитектура. Слишком много терминов и разночтений. Попробую пояснить оба этих понятия.

Rich Domain Model, в простонародье, толстая модель, концепция построения логической архитектуры, в которых бизнес-объекты содержат бизнес-логику. Или можно наоборот, бизнес-логика содержит состояние бизнес-объектов.

Anemic Domain Model – почему-то некоторые называют стройной моделью, но особо и не слышал о нормальном(адекватном) русском переводе данного термина. Лично я обычно называю нетолстой моделью. Так понятней. Итак, Anemic Domain Model – концепция построение логической архитектуры, в которой состояние бизнес-объектов разнесено с объектами бизнес-логики обрабатывающих их.

Эти два термина в английском варианте я и буду использовать в дальнейшем, во избежание разночтений.

ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model. Под Domain Model некоторые понимают Rich Domain Model, что не является правдой, под Transaction Script – Anemic Domain Model. Но если с первым термином не очень логично, второй термин сразу ушел в небытие, и обществом принят не был.

МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
В Anemic:

Employer[] OrganizationService.GetEmployers(Organization org){…}

В Rich:

Employer[] Organization.GetEmployers(){…}

Это немного, однако оно приводит к значительном различии в архитектуре. И та, и другая модель имеет те, или иные достоинства, и недостатки:

Преимущества Anemic:
1. Простота построения. Это большой плюс, ибо главная задача архитектора, реализация функциональности за меньшие деньги. 90 процентов решений, могут быть построены в данной модели и это будет на порядок дешевле.
2. Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятсвенно и идентично сериализован/десериализован между физическими слоями. В большинстве, бизнес-объект как бизнес-сущность не меняется при переносе между слоями.
3. Прогнозируемость и управляемость вплоть до DAL. Что под этим понимается. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных(и зачастую не обычным редактирование SQL). В Anemic, вы спокойно можете провести тот, или иной сценарий через соседний сервис, который будет работать именно над этом тяжелым сценарием. В Rich — проблема как с прогнозом результирующего запроса, и с его оптимизацией.
4. Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Что иногда выливается в проблемы(например, когда объект только что создан, не имеет идентификатора, и не имеет тех, или иных ссылок). Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.

Преимущества Rich:
1. Простота использования. Объекты всегда под рукой. Средства обработки объектов, также под рукой. Использовать Rich – значительно проще, особенно когда в проекте новичок.
2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. Но тут следует упомянуть, что те изменения, которые касаются состояния, также отслеживаются компиляцией со статической типизацией в Anemic, что покрывает большее количество таких проблем.
3. Меньшее количество мусора. В Anemic приходится отслеживать, чтобы в ворохе сервисов не делали свои велосипеды. В Rich c этим меньше проблем в силу более сильной локализации логики.

Действительность.
Чисто Anemic, а тем более Rich в абсолютно чистом виде не бывает. Бизнес-объект как минимум содержит типизацию, что является частью бизнес-логики, в Rich – по любому приходится делать более высокоуровневые сервисы.

Показания к использованию.
Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации. Это сгладит недостатки модели.

О себе.
Долгое стародавнее время писал в стиле Rich(вынужден сказать, что не по поводу). Последнее время(а это n лет) пишу только в Anemic.
Теперича можно обсуждать, осуждать, предлагать пойти в лесок с топором погуляти и etc

Здравствуйте, GlebZ, Вы писали:

GZ>ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model.
Автор терминов Rich Domain Model и Anemic Domain Model — Фаулер.
Кратко говоря — Фаулер разбирая Domain Model говорит, что Rich — это правильная Domain Model, а Anemic — не правильная. Таким образом, к Transaction Sript это не имеет никакого отношения, если говорить о Фаулеровских терминах.
Так что прежде чем писать про Anemic vs Rich, не плохобы написать, что такое вообще Domain Model, чего я добивался еще в прошлый раз.

GZ>Под Domain Model некоторые понимают Rich Domain Model, что не является правдой,
Это ты Фаулеру скажи..

GZ>МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
Либо ты сам себе противоречишь, либо я не понимаю о чем ты.

GZ>2. Инкапсуляция.
Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?

GZ>Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс.
Проблема только в том, что в реальной жизни один фиг в бизнес объекте есть прямой доступ к данным, максимум обернутыми в свойства. В противном случае объект должен знать обо всех сценариях своего использования и меняться при появлении каждого нового сценария.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, GlebZ, Вы писали:

GZ>>ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model.
IB>Автор терминов Rich Domain Model и Anemic Domain Model — Фаулер.
+1
IB>Кратко говоря — Фаулер разбирая Domain Model говорит, что Rich — это правильная Domain Model, а Anemic — не правильная. Таким образом, к Transaction Sript это не имеет никакого отношения, если говорить о Фаулеровских терминах.
-1 Только не тебе, а Фаулеру. В книжке, в которой он полновесно хотел описать все паттерны, он вполне справедливо запутался. Если брать саму постановку вопроса — то Anemic и Transaction Script, одно и то же. Далее, после данной книги, когда оказалось что Transaction Script может описывать предметную область, а он это не учел, то тут и начался у него переполох в уме.
IB>Так что прежде чем писать про Anemic vs Rich, не плохобы написать, что такое вообще Domain Model, чего я добивался еще в прошлый раз.
Что такое модель предметной области? Она есть всегда и везде. Ибо по ней и создается архитектура.

GZ>>Под Domain Model некоторые понимают Rich Domain Model, что не является правдой,
IB>Это ты Фаулеру скажи..
Ежели смотреть обсуждения нескольких лет назад, то ему это уже говорили. Что и породило новую терминологию.

GZ>>МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
IB>Либо ты сам себе противоречишь, либо я не понимаю о чем ты.
Ничего не противоречу. Между функцией получения, и ссылкой есть большая разница. И она сколько не физическая, а логическая.

GZ>>2. Инкапсуляция.
IB>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?
Я это уже сказал.

GZ>>Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс.
IB>Проблема только в том, что в реальной жизни один фиг в бизнес объекте есть прямой доступ к данным, максимум обернутыми в свойства. В противном случае объект должен знать обо всех сценариях своего использования и меняться при появлении каждого нового сценария.
Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте.

Здравствуйте, GlebZ, Вы писали:

GZ>Что такое модель предметной области? Она есть всегда и везде. Ибо по ней и создается архитектура.
Эта "модель предметной области" всегда напрямую выражается в коде?

GZ>Ничего не противоречу. Между функцией получения, и ссылкой есть большая разница. И она сколько не физическая, а логическая.
Хрен редьки не слаще.

IB>>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?
GZ>Я это уже сказал.
Ну и зря, инкапсуляция в стройной модели ничуть не ниже, а как правило и выше.

GZ>Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте.
так прикладному программисту они действительно не нужны, а тому, который всю логику вокург ACL реализует, очень даже пригодятся.

Здравствуйте, GlebZ, Вы писали:


GZ>Преимущества Rich:
GZ>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике.
Недоступно состояние? а как пользователю на экране это недступное состояние показать?
А если есть функционал, затрагивающий несколько объектов?

Кстати, инкаписуляция != data hiding.

Здравствуйте, IB, Вы писали:

IB>Эта "модель предметной области" всегда напрямую выражается в коде?
Зависит от архитектора. Модель предметной области — термин постановки а не архитектуры. В лучшем случае, набор документации написанной постановщиком, в худшем — абстрактная модель в голове программиста.

IB>Хрен редьки не слаще.
Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать.

IB>>>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?
GZ>>Я это уже сказал.
IB>Ну и зря, инкапсуляция в стройной модели ничуть не ниже, а как правило и выше.
Если ты об этом? здесь

Автор: IB
Дата: 25.10.07

То это был неправильный твой перевод. Говорилось о вреде излишней инкапсуляции(в чем я абсолютно согласен ибо уменьшают cohesion), а не о том что она выше. По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные.

GZ>>Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте.
IB>так прикладному программисту они действительно не нужны, а тому, который всю логику вокург ACL реализует, очень даже пригодятся.
Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит.

Здравствуйте, gandjustas, Вы писали:

GZ>>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике.
G>Недоступно состояние? а как пользователю на экране это недступное состояние показать?
G>Кстати, инкаписуляция != data hiding.
Блин.... Ёкарный бабай. Ну ты тыкни где я писал что инкапсуляция = data hiding. Найди выдели и тыкни пальцем и выругайся. Мы понимать что написано умеем? Мне нужно описывать все терминалогию, от инкапсуляции до понятия байта?

G>А если есть функционал, затрагивающий несколько объектов?
А ты всегда и все показываешь? Списки доступа, гуиды, средства построения деревьев при адресации по идентификаторам?

Здравствуйте, GlebZ, Вы писали:

Неправильно откопировал
G>>Недоступно состояние? а как пользователю на экране это недступное состояние показать?
GZ>А ты всегда и все показываешь? Списки доступа, гуиды, средства построения деревьев при адресации по идентификаторам?

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, gandjustas, Вы писали:

GZ>>>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике.
G>>Недоступно состояние? а как пользователю на экране это недступное состояние показать?
G>>Кстати, инкаписуляция != data hiding.
GZ>Блин.... Ёкарный бабай. Ну ты тыкни где я писал что инкапсуляция = data hiding. Найди выдели и тыкни пальцем и выругайся.
Выделил. Если надо показывать на экране, то это data hiding.

G>>А если есть функционал, затрагивающий несколько объектов?
GZ>А ты всегда и все показываешь? Списки доступа, гуиды,
нет, я их даже не считываю.

GZ>средства построения деревьев при адресации по идентификаторам?
такое тоже в базе хранится?

Здравствуйте, GlebZ, Вы писали:

GZ>Что-то слишком уж разнятся понимания что же такое Толстая архитектура, а что такое стройная архитектура. Слишком много терминов и разночтений. Попробую пояснить оба этих понятия.

[..]

GZ>Показания к использованию.
GZ>Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации.
Это сгладит недостатки модели.

Можно вставить свои пять копеек по поводу использования? Вы говорите о том, что нужно выбрать; наверное, правильнее будет говорить о том, в какую сторону делать уклон, потому что в чистом виде все равно не получится.
Ну и вдобавок что хотел сказать по поводу критериев выбора -- есть еще понятие data-centric и object-centric model. Если вы придерживаетесь первого (data-centric), то стоит двигаться в сторону anemic. Если object-centric -- то к RichModel. Потому как на примере своего приложения -- несмотря на то, что очень много сущностей, но за счет их data-centric природы anemic model неплохо удовлетворяет нужды.

И еще -- если есть колебания, что выбрать, можно грубо можно пользоваться простой аналогией: Rich Model <--> Active Record. Если AR устраивает, можно выбирать rich model, если же выглядит неприемлемой -- стоит грести к anemic.

Здравствуйте, gandjustas, Вы писали:

GZ>Программисту, использующему данный объект, недоступно его состояние, кроме как через определенный интерфейс.
Объясняю. Только не выделенное, а всю фразу. Чтобы параноидально по полочкам.
Инкапсуляция — средство локализации функционала в сухом и потребном месте. Для локализации функционала, нужно иметь некоторый интерфейс(в фразе это слово присутсвует). Все что за этим интерфейсом, как бы то ни было, данные, функции, объекты, мамонты и мамонтихи, скрываются. Таким образом, я нигде не писал что data hiding=incapsulation. Но то что data hiding может являться средством инкапсуляции, и в большинстве случаев для людей с головой является таковым, я как то даже стесняюсь говорить.

Здравствуйте, GlebZ, Вы писали:

GZ>Зависит от архитектора.
GZ>Модель предметной области — термин постановки а не архитектуры. В лучшем случае, набор документации написанной постановщиком, в худшем — абстрактная модель в голове программиста.
Отлично, так в какой момент это все переходит в Domain Model в терминах Фаулера? он-то говорит именно об архитектурном решении.

GZ>Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать.
Вопрос использования.

IB>То это был неправильный твой перевод.
Правильный.

IB>Говорилось о вреде излишней инкапсуляции(в чем я абсолютно согласен ибо уменьшают cohesion), а не о том что она выше.
Именно о том, что она выше.

IB> По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные.
В том-то и дело, что не будут они у тебя приватными, в реальной жизни. Иначе получается как раз та самая "излишняя инкапсуляция"

GZ>Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит.
Не об этом, а о том, что у того, кто разрабатывает логику работы вокруг ACL все равно придется делать это отдельной сущностью, так как всю эту логику в отдельный класс не запихнешь уж очень она развесистая.

Здравствуйте, GlebZ, Вы писали:

МИФЫ ходящие по rsdn.
МИФ №2
Вся логика находися в бизнес-объекта. Господа и товарищи... Никто из приверженцев Rich модели из ума не выжил. Сложные сценарии не инкапсулируются в самих бизнес-объектах.

Миф №3
У толстой модели нет единой точки входа. Точка входа всегда есть. Называется фасад. Для него больше придется положить усилий и трудов, но он есть. И в нем, можно создавать контексты транзакций, аутентификацию, и проводить сериализацию.

Здравствуйте, IB, Вы писали:

IB>Отлично, так в какой момент это все переходит в Domain Model в терминах Фаулера? он-то говорит именно об архитектурном решении.
Ладно, поехали снова. Мне кажется мы больше издеваемся друг над другом, чем ищем вселенское благо. Давай забудем об архитектуре как таковой, а займемся буквоедством, то бишь паттернами.
Берем сайт Фаулера:
Для Domain Model:

An object model of the domain that incorporates both behavior and data.

Для Transaction Script:

Organizes business logic by procedures where each procedure handles a single request from the presentation.

Надо отдать ему должное, в его вышеупомянутой книжке описывается то же самое.
Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
Второе — Transaction Script. И совершенно ничего не говорится о том, что сами параметры процедур, точно также могут описывать предметную область. И тут начинается буза. С одной стороны, если мы используем бизнес объекты в Transaction Script, то чем это не object model? Можно спокойно построить логическую диаграмму объектов. То есть это же получится Domain Model? Фаулер вышел из этой загвоздки, разделением понятия Domain Model на паттерн и антипаттерн. Ну что же делать, дикари-с. Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.

GZ>>Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать.
IB>Вопрос использования.
Перечитай весь параграф. Я говорил именно об инстанцировании.

IB>> По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные.
IB>В том-то и дело, что не будут они у тебя приватными, в реальной жизни.
Смотря для кого? DAL — это также инкапсуляция работы с БД. Мы не говорим что оно инкапсулировано от самих объектов DAL. Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше.
IB>Иначе получается как раз та самая "излишняя инкапсуляция"
Инкапсуляция не может быть измерена. В отличие от Low Cohesion, High Coupling.

GZ>>Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит.
IB>Не об этом, а о том, что у того, кто разрабатывает логику работы вокруг ACL все равно придется делать это отдельной сущностью, так как всю эту логику в отдельный класс не запихнешь уж очень она развесистая.
Абсолютно верно. Но тут как раз два подхода. Для одного подхода — это сервис. Для второго подхода, это вопрос иерархии наследования.
Кстати, это действительно интересный пример разницы:
Например, в случае anemic:
bool ACLService.CanEdit(Guid id, Guid idUser);
в случае Rich:
bool MyEditableObject.CanEdit(Guid idUser);
Вызовы похожи, а вот реализация совершенно разная.
В первом случае, мы имеем сервис в котором мы можем получить подсчитать список доступа для данного объекта, например какие пользователи могут пользоваться этим объектом и закэшировать эту инфу в самом сервисе. Нам не нужен сам объект по сути. Мы вполне можем его не загружать когда он не требуется.
Во втором случае, мы можем в Lazy Load точно также рассчитать реальный ACL через определенный сервис, и хранить его в самом объекте, закэшировав сам объект. Второе в данном случае менее эффективно потому как приходится загружать объект, но несколько более эффектиный кэш. Пока не изменен список доступа определенного пользователя все более менее, но если он поменялся. В результате, в ACLService мы вполне достойно можем почистить кэш контролируемый нами. А в случае с бизнес объектом, нам придется высчитывать кто есть лишний на этом празднике жизни, и как ему об этом сообщить. Задача вполне решаемая, но все таки обладающая некоторой трудоемкостью.
Далее, тут у нас начинается коренная доработка, в которой говорится что доступ к MyEditableObject складывается от ACL не только самого объекта, но еще и его непосредственного parent. И тут начинаются траблы. Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации. Injection тут не поможет по той же причине, и нам приходится героически переделывать вызовы сервиса там, где информация о том что это именно MyEditableObject присутсвует. В случае Rich — нам достаточно переделать реализацию CanEdit, ну например, на вызов return ACLService.CanEdit(id, parentId, userId) или вообще сделать ACLEditableObjService. Инкапсуляция в действии.
Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.

Здравствуйте, GlebZ, Вы писали:

GZ>Organizes business logic by procedures where each procedure handles a single request from the presentation.
Какое-то странное определение, ограничивающие Transaction Script презентацией, типа логики не может быть вообще.

GZ>Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
Это ты уже спекуляциями начинаешь заниматься — гаданием по Фаулеру, что же он имел ввиду.

GZ> Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.
Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)

GZ>Я говорил именно об инстанцировании.
А я об использовании.

GZ>Смотря для кого?
Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.

GZ>Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше.
Каким боком?

GZ>Инкапсуляция не может быть измерена.
Инкапсуляция отлично меряется, что подробно расписано у того же Меерса.

GZ>Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации.
Мы можем прекрасным образом использовать ACLService.CanEdit передав ему всю необходимую информацию — либо самого parent-а, либо построив бизнес объект таким образом, чтобы вся необходимая информация уже была в нем.
Разница лишь в том, что в отличии от Rich ты сделаешь это явно, причем именно там где полагается — при обращении к ACL, а в случае Rich, спустя какое-то время ты будешь сильно удивляться — какого хрена при обращении к MyObj.CanEdit он еще и к родителю лезет.

GZ> В случае Rich — нам достаточно переделать реализацию CanEdit,
В стройной модели тоже самое.

GZ> Инкапсуляция в действии.
Во-во, излишняя инкапсуляция в действии.

GZ>Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.
Я думаю — ты уже понял, где ошибался? =)

Здравствуйте, GlebZ, Вы писали:

А знаете в чём здесь загвоздка?

Надо разделять БЛ и логику предметной области (намеренно не использую слово Domain, т.к. его все по разному понимают).

Что такое предметная область? Это грубо говоря поле игры заказчика, то что никак не зависит от его желаний/способа организации бизнеса.

Например независимо от желания аэроперевозчика у самолётов конечная вместимость. Ограничение на нерастяжимость самолёта — часть предметной области и по-хорошему должно проверяться силами самой model (в идеале при попытке изменения в дополнение к проверке при сохранении изменений).

И так набирается куча логики, которая к самой БЛ никакого отношения не имеет. Разгрузка БЛ позволяет нехило упростить саппорт и изменение — т.к. БЛ выглядит как последовательность операций над предметной областью, элементарно расписывается и проверяется даже неспециалистами в программировании.

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

Об этом Эванс неплохо писал в "Domain-driven-design: tackling the complexity in the heart of software". Правда во второй части он зачем-то опровергает сам себя и смешивает БЛ и domain model обратно

Проблему надо просто решать на уровне архитектуры приложения а не ждать пока она вылезет в кривом дизайне DAL/контроллера. Тогда и не будет споров "anemic vs rich" и "mvc or not mvc".

Any comments?

Здравствуйте, meowth, Вы писали:

M>И еще -- если есть колебания, что выбрать, можно грубо можно пользоваться простой аналогией: Rich Model <--> Active Record. Если AR устраивает, можно выбирать rich model, если же выглядит неприемлемой -- стоит грести к anemic.

-1, но что-то в этом есть.

Здравствуйте, IB:

IB>Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)

Если я нигде ничего не вру, там шла речь в контексте реализации UoW, да ещё и бизнес-процессы упоминались (мы говорим о его книжке "enterprise что-тотам"?).

А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами. И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".

Кстати, не втыкали в большинство описаний "типовых моделей бизнес процессов"? Там в основном идёт речь именно о воркфлоу как поэтапном изменении состояния. И процессы и ресурсы явно ставятся ортогонально друг другу. Так что это чуть ли не специфика бизнес-логики выходит.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

S>А знаете в чём здесь загвоздка?

S>Надо разделять БЛ и логику предметной области (намеренно не использую слово Domain, т.к. его все по разному понимают).
S>Что такое предметная область? Это грубо говоря поле игры заказчика, то что никак не зависит от его желаний/способа организации бизнеса.
Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.
В подавляющем большинстве случаев business-transactions сводятся к транзакциям БД. В более сложных случаях имеет смысл умышленно сводить бизнес-транзакции к системным транзакциям.

S>Например независимо от желания аэроперевозчика у самолётов конечная вместимость. Ограничение на нерастяжимость самолёта — часть предметной области и по-хорошему должно проверяться силами самой model (в идеале при попытке изменения в дополнение к проверке при сохранении изменений).
А вот тут возникает самый нтересный вопрос: когда проверять business-rules.

Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.


ЗЫ. Я еще не упоминул про busines-operations, которые состоят из множества business-transactions, возможо растянутых по времени.

Здравствуйте, gandjustas, Вы писали:

G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей.

Можно ссылку на выделенное?

G> Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

Мне кажется ты приписываешь DDD выдуманные недостатки, а потом их сокрушительно критикуешь.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, gandjustas, Вы писали:

G>>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей.

Z>Можно ссылку на выделенное?
Я ссылки не собираю. Можно посмотреть что тут пишут на форуме приверженцы жирной модели. Даже большой холивар был на эту тему.

G>> Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

Z>Мне кажется ты приписываешь DDD выдуманные недостатки, а потом их сокрушительно критикуешь.
Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.

Здравствуйте, gandjustas, Вы писали:

G>Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.

Речь идёт слегка не о том: в поведении приложения есть грубо говоря два уровня ограничений: что оно может делать и что от приложения хочет заказчик. Возвращаясь к аналогии с авиаперевозчиком, полётные планы (а это не только ограничения, это куча муторной логики) должны быть зарегистрированы и соответствовать стандартам — это часть предметной области. Разумеется, работа с _конкретными_ планами (нюансы типа соответствия законодательству кучи стран) — это как раз бизнес логика.

Разница тут совсем неочевидна, но чем больше у вас разноплановых взаимодействующих систем, тем проще её увидеть.

---

G>А вот тут возникает самый нтересный вопрос: когда проверять business-rules.
Согласен. Сразу disclaimer — я говорю главным образом о толстых клиентах со statefull-логикой.

G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.

Ну про DDD не надо. Эванс в первой части (когда он рассказывает что такое модель предметной области) нехило противоречит сам себе во второй (когда он начинает лепить всё в одну кучу).

Кстати, у нас локальная валидация на клиентах именно так и работает. Не всех ограничений конеш, а именно ограничений предметной области, их обычно немного. Да и то, это в основном не валидация пользовательского ввода (это к UI layer), а ассерты для поиска багов. Ещё я не совсем понял почему "проверки на каждый чих" — это признак Rich модели: эти проверки вполне могут быть оторваны от конкретного представления данных.

Скорее всего у нас просто разные предметные области — я первый убъюсь об стену если потребуется делать сложную валидацию на stateless аппсервере.

G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.

А эти варианты не отменяют друг друга: проверка при сохранении обязательно должна быть и в идеале должна делаться силами СУБД.

---

G>Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.

Эххх... Я тоже так думал. А потом радостно убивался об стену. Чем больше систем работает с одними и теми же данными — тем больше коллизий.
Тут речь идёт даже не о загрузке самолёта, а о информации о конкретном рейсе. Эта информация используется при бронировании билетов (тут тоже целый цирк включая работу с турагенствами), уходит в отчёт что подаётся при регистрации вылета (сорри, терминологию сильно подзабыл, да и не специалист я, так, интересовался), ещё может понадобиться в налоговую/для отчётов и аналитики.

В идеале информация о местах _изменяться_ будет в двух сценариях: бронирование билетов и покупка билетов. Но даже в этих двух сценариях структура данных будет очень нехило различаться, общих пересечений будет не так уж и много. Поэтому проще сделать сервис резервирования мест (будет дёргаться при начале обслуживания) и проверки в СУБД при любом изменении соответствующих данных.

Почему при любом? Потому что самолёт может быть заменён в любой момент (не совсем так, для простоты оставим), разорваться договор на транзит и т.п.
Причём заметьте — эти нюансы нифига не бизнес логика, про них стараются не упоминать в требованиях (ну кто ж признается что у него самолёты по пять раз на дню в сервисе). Эту инфу можно выудить либо очень тщательно покопавшись в предметной области самостоятельно, либо после кучи интерьвю со сторонними специалистами. Причём со специалистами, которые могут связно объяснить как оно работает и почему именно так. Это настоящий талант, и таких людей бывает крайне тяжко найти.

G>ЗЫ. Я еще не упоминул про busines-operations, которые состоят из множества business-transactions, возможо растянутых по времени.

Охх. Это отдельная тема. И так раздули.

P.S. Если я вас напрягаю — скажете, закруглимся

Здравствуйте, Sinix, Вы писали:

S>Если я нигде ничего не вру, там шла речь в контексте реализации UoW, да ещё и бизнес-процессы упоминались (мы говорим о его книжке "enterprise что-тотам"?).
Нет. Речь шла о его статье про антипаттерн Anemic Domain Model. (http://www.martinfowler.com/bliki/AnemicDomainModel.html)
Конкретно:

By pulling all the behavior out into services, however, you essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring.

Правда дальше у него идет оговорочка

As I discussed in P of EAA, Domain Models aren't always the best tool.

Но он нигде не говорит, что же это за такие advantages, которые domain model can bring.

S>А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами.
А что за проблемы у ООП с управлением процессами?

S> И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".
Бррр... Собственно я с Фаулером не согласен прежде всего в том, что Anemic — это процедурное программирование. Он там еще пишет, что ОО-дизайн — это обязательно логика вместе с данными, так вот это полная пурга, как-то он очень узко и наивно ОО-дизайн представляет. Как только данные становятся персистентными, делать им вместе с логикой нечего — жизненный цикл разный, но при этом это ни на каплю не противоречит правильному ОО-дизайну.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.

S>Речь идёт слегка не о том: в поведении приложения есть грубо говоря два уровня ограничений: что оно может делать и что от приложения хочет заказчик. Возвращаясь к аналогии с авиаперевозчиком, полётные планы (а это не только ограничения, это куча муторной логики) должны быть зарегистрированы и соответствовать стандартам — это часть предметной области. Разумеется, работа с _конкретными_ планами (нюансы типа соответствия законодательству кучи стран) — это как раз бизнес логика.
С точки зрения программы все равно откуда взялись требования — является ли это желанием заказчика или каким-либо законом.

S>Разница тут совсем неочевидна, но чем больше у вас разноплановых взаимодействующих систем, тем проще её увидеть.
Разницы на самом деле нету, она только в голове проектировщика.

S>

---

G>>А вот тут возникает самый нтересный вопрос: когда проверять business-rules.
S>Согласен. Сразу disclaimer — я говорю главным образом о толстых клиентах со statefull-логикой.
Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
Я вообще склонен считать такие случаи паталогическими.

S>Кстати, у нас локальная валидация на клиентах именно так и работает. Не всех ограничений конеш, а именно ограничений предметной области, их обычно немного. Да и то, это в основном не валидация пользовательского ввода (это к UI layer), а ассерты для поиска багов.
Для поиска багов лучше тесты.

S>Ещё я не совсем понял почему "проверки на каждый чих" — это признак Rich модели: эти проверки вполне могут быть оторваны от конкретного представления данных.
Проверки на каждый чих избыточны. Реально необходима только одна проверка при сохранении данных. Для удобства пользователей делают дополнительные проверки.
Если же проверки засунты в объекты, то проверки будут именно на каждый чих.

S>Скорее всего у нас просто разные предметные области — я первый убъюсь об стену если потребуется делать сложную валидацию на stateless аппсервере.
От предметтной области мало зависит главное правильно разделить на business-rules и preconditions чтобы ничего лишнего не проверять.

G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
S>А эти варианты не отменяют друг друга: проверка при сохранении обязательно должна быть и в идеале должна делаться силами СУБД.
Как уже писал выше при наличии проверки при сохранении остальные проверки только для удобства.

S>

---

G>>Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.

S>Эххх... Я тоже так думал. А потом радостно убивался об стену. Чем больше систем работает с одними и теми же данными — тем больше коллизий. (*остальное опущено*)

Все что написано сильно зависит от предметной области и желаний заказчика.

Здравствуйте, IB!

IB>Нет. Речь шла о его статье про антипаттерн Anemic Domain Model. (http://www.martinfowler.com/bliki/AnemicDomainModel.html)
Ну вот — влез не с тем и не туда

S>>А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами.
IB>А что за проблемы у ООП с управлением процессами?
Эххх, мой кривой язык...
Проблемы не у ООП, а у товарищей что пытаются изобразить динамически конфигурируемый DSL силами ООП.


S>> И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".
IB>Бррр... Собственно я с Фаулером не согласен прежде всего в том, что Anemic — это процедурное программирование.
Да-да, тут вы меня поняли верно.

IB> Он там еще пишет, что ОО-дизайн — это обязательно логика вместе с данными, так вот это полная пурга, как-то он очень узко и наивно ОО-дизайн представляет. Как только данные становятся персистентными, делать им вместе с логикой нечего — жизненный цикл разный, но при этом это ни на каплю не противоречит правильному ОО-дизайну.
+5.

Закругляемся? // А то щас долго расшаркиваться будем какие мы оба хорошие...

Здравствуйте, gandjustas, Вы писали:

G>С точки зрения программы все равно откуда взялись требования — является ли это желанием заказчика или каким-либо законом.
G>Разницы на самом деле нету, она только в голове проектировщика.

Щасс ответим — это вы хорошую тему подняли

Не обижайтесь, но у вас какое-то идеализированное представление о проектировании систем — берём требования, реализуем и все щасливы. Нифига!

• Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
  
• Во-вторых, требования заказчика не всегда бывают выполнимыми: их нужно прноверять.
  
• В-третьих если вам потребуется взаимодействие с внешними системами, от вас потребуется громадная куча фич, которые очевидны из предметной области, но не указаны в требованиях.
  
• В-четвёртых у модели предметной области приоритет банально выше: она стабильнее, требования заказчика гарантированно не могут выйти за пределы предметной области (точнее, могут захватить другую предметную область, но это другой разговор) и, самое главное, правила предметной области не зависят от хотелок заказчика/проектировщика и тем самым делает предсказуемым процесс разработки.

Грубо говоря требования описывают внешний интерфейс системы (не только и не столько UI разумеется), а ограничения предметной области позволяет обоснованно говорить о дизайне системы. Во всяком случае, с большей уверенностью чем при проектировании от требований

Разумеется, в жизни не всё так радужно, но если видите что я где-то не прав — давайте разберём по пунктам, ок?

---

G>Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
G>Я вообще склонен считать такие случаи паталогическими.
G>Для поиска багов лучше тесты.

Видно я невнятно написал — здесь я с вами в принципе согласен. Сама логика может жить и на сервере — ничего не мешает. Дело именно в общих проверках, независимых от конкретного сценария.

[ОФФТОП]
Про тесты: одно другого не отменяет. Лично мне куда проще саппортить такой код:

void SomeMethod(string arg1, params int[] indexes)
{
  Code.NotNullOrEmpty(arg1, "arg1");
  Code.NotNull(indexes, "indexes");
  Code.GreaterThenOrEqual(indexes.Length, "indexes.Length", 5);
  Code.AssertState(CanDoSomeOperation, @"Some detailed exception message");

  // code goes here
}

Сразу виден data contract + есть возможность отключать проверки по необходимости.
[/ОФФТОП]

G>Проверки на каждый чих избыточны. Реально необходима только одна проверка при сохранении данных. Для удобства пользователей делают дополнительные проверки.
G>Если же проверки засунты в объекты, то проверки будут именно на каждый чих.

Ну да, я примерно это и имел в виду: проверки при изменении в основном работают в UI layer и в основном для удобства пользователей. Ассерты — это так, дополнительная подстраховка, к тому же отключаемая.

Здравствуйте, gandjustas, Вы писали:

G>Я ссылки не собираю. Можно посмотреть что тут пишут на форуме приверженцы жирной модели. Даже большой холивар был на эту тему.

Глядя на количество негативных постов про .net еще не пропало желание его использовать? Я вот регулярно натыкаюсь на ругательства по поводу быстродействия, GC, JIT и C# от людей которые только что вошли в технологию.

G>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал.

Чем он ужасен? Что мешает отказаться от него в случаях когда он приносит неудобства? Каким образом

G> Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.

IB написал не один пост, что DDDшными средствами вообще ничего делать нельзя. Его я и сам читаю, если лияно у тебя есть аргументы по которым любое отображение информации надо делать неDDDшными средствами излагай.

Здравствуйте, Ziaw, Вы писали:

Z>Чем он ужасен? Что мешает отказаться от него в случаях когда он приносит неудобства? Каким образом
он привязан к рич модели?

Z>IB написал не один пост, что DDDшными средствами вообще ничего делать нельзя. Его я и сам читаю, если лично у тебя есть аргументы по которым любое отображение информации надо делать неDDDшными средствами излагай.

Здравствуйте, IB, Вы писали:

GZ>>Organizes business logic by procedures where each procedure handles a single request from the presentation.
IB>Какое-то странное определение, ограничивающие Transaction Script презентацией, типа логики не может быть вообще.
+1
GZ>>Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
IB>Это ты уже спекуляциями начинаешь заниматься — гаданием по Фаулеру, что же он имел ввиду.
Ну а что еще остается если изначально введеная им терминология неверна и алогична.

GZ>> Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.
IB>Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)
+1

GZ>>Я говорил именно об инстанцировании.
IB>А я об использовании.
Фраза вырванная из контекста — теряет смысл и может быть неверно истолкована.

GZ>>Смотря для кого?
IB>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
Ну а если не стоит его публиковать?

GZ>>Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше.
IB>Каким боком?
Ты не влезешь в базу данных напрямки. Только опосредовано интерфейсу.

GZ>>Инкапсуляция не может быть измерена.
IB>Инкапсуляция отлично меряется, что подробно расписано у того же Меерса.
Не знал о такой метрике. Интересно послушать как.

GZ>>Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации.
IB>Мы можем прекрасным образом использовать ACLService.CanEdit передав ему всю необходимую информацию — либо самого parent-а,
Либо проявив недюженные экстрансенсорные способности изначально записать в контракт идентификатор парента. Но это изменение границ проекта на итерации. За это неплохо и по шапке получить.
IB>либо построив бизнес объект таким образом, чтобы вся необходимая информация уже была в нем.
А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.

IB>Разница лишь в том, что в отличии от Rich ты сделаешь это явно, причем именно там где полагается — при обращении к ACL, а в случае Rich, спустя какое-то время ты будешь сильно удивляться — какого хрена при обращении к MyObj.CanEdit он еще и к родителю лезет.
Угу. Пункт 3 преимуществ Anemic

GZ>> В случае Rich — нам достаточно переделать реализацию CanEdit,
IB>В стройной модели тоже самое.
Противоречишь.

GZ>>Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.
IB>Я думаю — ты уже понял, где ошибался? =)
Нет. Вот чего не понял, того не понял.

Здравствуйте, gandjustas, Вы писали:

G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
Никто не мешает совмещать. Простейшие проверки можно сделать в сеттерах — тогда они будут срабатывать еще и прямо при редактировании в гриде или прибинденных полях редактирования — что по моему скромному мнению есть очень удобно.
Более сложные проверки можно вынести либо в метод Validate либо в какой-то ValidationService().

Здравствуйте, GlebZ, Вы писали:

Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.

Тока в конце написал бы что последнее вермя (не лет ) использую рич модель.

Кстати слегка коробит от термина "толстая модель"...

Здравствуйте, Ziaw, Вы писали:

Z>IB написал не один пост, что DDDшными средствами вообще ничего делать нельзя.
Минуточку
Во-первых я про DDD вообще ни слова.
А во-вторых, я ни где не говорил что "нельзя", наоборот, можно все. Порой только диву даешься, какой причудливый код работает. Другое дело, что поддерживать и развивать такой код — вспотеешь.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.
Только не Иван Иванычь, а Сергей Петрович, не пароход, а два рубля и не выиграл, а проиграл.
То есть, как выясняется — все напутано.

MC>Кстати слегка коробит от термина "толстая модель"...
Прально, потому что она жирная..

Здравствуйте, GlebZ, Вы писали:

IB>>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
GZ>Ну а если не стоит его публиковать?
Рано или поздно все равно появится дополнительный сценарий, который потребует доступа к этому полю.

GZ>Ты не влезешь в базу данных напрямки. Только опосредовано интерфейсу.
Это всегда так, при любой модели.

GZ>Не знал о такой метрике. Интересно послушать как.
Почитай Меерса, в кратце — количество кода, которое потенциально может быть затронуто, при изменении объекта.

GZ>Либо проявив недюженные экстрансенсорные способности изначально записать в контракт идентификатор парента.
Никакой экстрасенсорики не надо. Вполне логично, что изменение требований безопасности потребовало изменения контракта метода, который эту безопасность осуществляет.

GZ>А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.
Нужен, ты же не одно поле поднимаешь.

GZ>Нет. Вот чего не понял, того не понял.
Стройная модель лучше, чем жирная, подходит для предложенного тобой изменения, а вовсе не наоборот.

Здравствуйте, IB, Вы писали:

IB>>>Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
GZ>>Ну а если не стоит его публиковать?
IB>Рано или поздно все равно появится дополнительный сценарий, который потребует доступа к этому полю.
Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.

IB>Почитай Меерса, в кратце — количество кода, которое потенциально может быть затронуто, при изменении объекта.
Это не мера измерения. В основном измеряют цикломатическую сложность, coupling и cohesion. Для последних есть большое кол-во подвидов. Верная инкапсуляция, это всего лишь инструмент для оптимального coupling и cohesion.

GZ>>Либо проявив недюженные экстрансенсорные способности изначально записать в контракт идентификатор парента.
IB>Никакой экстрасенсорики не надо. Вполне логично, что изменение требований безопасности потребовало изменения контракта метода, который эту безопасность осуществляет.
Ну, о чем и говорилось. И соответвенно, как минимум во все методы вызывающие данный метод.

GZ>>А тут мы убиваем некоторый бонус Anemic. Бизнес-объект в первоначальном варианте был не нужен. Его вполне можно было бы и не поднимать.
IB>Нужен, ты же не одно поле поднимаешь.
Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?

GZ>>Нет. Вот чего не понял, того не понял.
IB>Стройная модель лучше, чем жирная, подходит для предложенного тобой изменения, а вовсе не наоборот.
Опять?

+1
вот чего не хватает так это законченных примеров.
может в инете где-нить есть?

Здравствуйте, GlebZ, Вы писали:

GZ>Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.
Она не предварительная.

GZ>Это не мера измерения.
А что же это?

GZ>В основном измеряют цикломатическую сложность, coupling и cohesion.
А не в основном?

GZ>Верная инкапсуляция, это всего лишь инструмент для оптимального coupling и cohesion.
Вот именно. Соответственно, если в случае одной инкапсуляции связность выше, значит инкапсуляция ниже, и наоборот.

GZ>Ну, о чем и говорилось. И соответвенно, как минимум во все методы вызывающие данный метод.
Это плохо? Еще раз — у тебя есть два варианта:
1. Изменить бизнес-объект таким образом, чтобы вся необходимая информация уже была в нем в момент вызова.
2. Явно передать всю необходимую информацию при вызове.
И оба эти варианта лучше чем неявное поднятие нового объекта в CanEdit
Собственно, есть и третий вариант — ты можешь проинжектить ACLService, сервисом работы с данными и опять-таки поднять неявно родительский объект в CanEdit, но так делать не стоит — это мало чем будет отличаться от жирной модели, просто лишний раз подтверждает, что стройная легко покрывает описанный тобой сценарий.

GZ>Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?
Я не про отдачу, а про то что в момент отдачи у тебя полюбому целый объект.

GZ>Опять?
Что опять?

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Супер, я давно хотел такое написать, а то реально получаеться что толчеться вода в ступе.
IB>Только не Иван Иванычь, а Сергей Петрович, не пароход, а два рубля и не выиграл, а проиграл.
IB>То есть, как выясняется — все напутано.

Эм, ты щас про что?

Здравствуйте, syrompe, Вы писали:

S>+1
S>вот чего не хватает так это законченных примеров.
S>может в инете где-нить есть?

Все есть причем и того и того, достаточно подыскать опенсорсную реализацию чего-то и там копать...

Для рич моделей есть очень хороший специально сделаный пример — DDD Sample. Несмотря на то что это сампл, там покрыты 90% всех ситуаций стандарного корпоративного приложения.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Эм, ты щас про что?
Про то что опысывая все это GlebZ, к сожалению много чего напутал и ясности не внес.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Эм, ты щас про что?
IB>Про то что опысывая все это GlebZ, к сожалению много чего напутал и ясности не внес.

Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

Да и мож не будут появляться фразы типа:
G>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
Могу и твоих фраз поискать про метод Сейв и тому подобное.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Ыыы, ну так напиши свое понимание этих моделей.
Я уже давно написал.

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...
Какой вопрос интересует?

MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.
Что тебе в моих постах не нравится?

Здравствуйте, IB, Вы писали:

MC>>Могу и твоих фраз поискать про метод Сейв и тому подобное.
IB>Что тебе в моих постах не нравится?

То же что и в постах gandjustas, сорри, но вы оба не шарите в рич моделях , .

Здравствуйте, GlebZ, Вы писали:

GZ>Преимущества Anemic:
GZ>1. Простота построения. Это большой плюс, ибо главная задача архитектора, реализация функциональности за меньшие деньги. 90 процентов решений, могут быть построены в данной модели и это будет на порядок дешевле.
GZ>2. Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятсвенно и идентично сериализован/десериализован между физическими слоями. В большинстве, бизнес-объект как бизнес-сущность не меняется при переносе между слоями.
GZ>3. Прогнозируемость и управляемость вплоть до DAL. Что под этим понимается. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных(и зачастую не обычным редактирование SQL). В Anemic, вы спокойно можете провести тот, или иной сценарий через соседний сервис, который будет работать именно над этом тяжелым сценарием. В Rich — проблема как с прогнозом результирующего запроса, и с его оптимизацией.
GZ>4. Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Что иногда выливается в проблемы(например, когда объект только что создан, не имеет идентификатора, и не имеет тех, или иных ссылок). Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.

Хотел бы подвергнуть сомнению все эти пункты:
1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
4) Постоянная валидность бизнес-объектов и RDM -- совершенно не связанные между собой аспекты, в случае ADM точно так же можно наложить ограничение постоянной валидности. К тому же современные средства валидации бизнес-объектов поддерживают несколько степеней валидности, в зависимости от контекста.

GZ>Показания к использованию.
GZ>Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации. Это сгладит недостатки модели.

То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM

P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно:
http://javatoday.ru/2009/03/rich-domain-model/

Здравствуйте, IB, Вы писали:

GZ>>Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.
IB>Она не предварительная.

GZ>>Это не мера измерения.
IB>А что же это?
Инструмент.

GZ>>В основном измеряют цикломатическую сложность, coupling и cohesion.
IB>А не в основном?
До хрена всего, а самое главное, разными способами. Только это для отдельной темы.

GZ>>Ну, о чем и говорилось. И соответвенно, как минимум во все методы вызывающие данный метод.
IB>Это плохо? Еще раз — у тебя есть два варианта:
IB>1. Изменить бизнес-объект таким образом, чтобы вся необходимая информация уже была в нем в момент вызова.
+-1 Только тогда это будет аналог Rich. Только значительно хуже. Ибо в Rich, можно спрятать дополнительную информацию за интерфейсом и загружать по мере надобности, а для некоторых сценариев вообще загружать вместе с основным объектом, в Anemic — он неделим.

IB>2. Явно передать всю необходимую информацию при вызове.
+1 Но проблема, что это надо передавать каждый раз в разных сценариях. Таким образом, ты и связываешь разные места с контрактом ACLService.CanEdit. Увеличиваешь cohesion.

IB>И оба эти варианта лучше чем неявное поднятие нового объекта в CanEdit
Ну наконец-то. Начинаю тебя понимать. Смотрим что было изначально:

инкапсуляция выше, ресурсоемкость тоже

Со вторым ты вроде согласен. А вот первое, тебе покоя не дает. Несмотря на конкретный пример.

IB>Собственно, есть и третий вариант — ты можешь проинжектить ACLService, сервисом работы с данными и опять-таки поднять неявно родительский объект в CanEdit, но так делать не стоит — это мало чем будет отличаться от жирной модели, просто лишний раз подтверждает, что стройная легко покрывает описанный тобой сценарий.
Это как раз чрезвычайно сильно изменяет модель относительно Rich. Тады ACLService придется понимать с каким именно объектом он имеет дело.

GZ>>Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?
IB>Я не про отдачу, а про то что в момент отдачи у тебя полюбому целый объект.
Нет. Это может быть список объектов которые можно редактировать. А может быть и список идентификаторов объектов которые можно редактировать.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

MC>Да и мож не будут появляться фразы типа:
G>>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.

Бгг, присоединяюсь )) Можно один топик с подтредом на каждого сильно разбирающегося в anemic и domain

Здравствуйте, Mike Chaliy, Вы писали:

MC>Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

MC>Да и мож не будут появляться фразы типа:
G>>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.

Сорри, как-то не так отправилось.

Бгг, присоединяюсь )) Можно один топик с подтредом на каждого сильно разбирающегося в anemic и domain

Здравствуйте, GlebZ, Вы писали:

GZ>Инструмент.
Инструмент — это инкапсуляция, и есть метрика правильности его применения.

GZ>+-1 Только тогда это будет аналог Rich.
Нет. Самый близкий аналог Rich — это третий способ.

GZ>Только значительно хуже. Ибо в Rich, можно спрятать дополнительную информацию за интерфейсом и загружать по мере надобности.
Значительно лучше. Это не дополнительная информация, это всегда необходимая информация.
Никто не собирается грузить родителя сразу, необходимая информация уже есть в дочернем, он самодостаточен, ему ничего не нужно.
Причем эта информация не является лишней, она необходима при каждой проверке доступа (и наверняка не только доступа, раз доступ на нее завязан).

GZ>+1 Но проблема, что это надо передавать каждый раз в разных сценариях.
Это не проблема. Это как раз хорошо. Я явно в каждом сценарии понимаю, что нужно и явно это передаю.
Причем забыть и не передать, я не могу — компилятор поправит. И явно передавая — четко понимаешь чего это стоит в каждом сценарии и каждый сценарий, при необходимости, ты можешь настроить отдельно, не трогая другие (например, в одном случае получая нужный объект из кеша, а в другом напрямую в обход всего, если это критично — инкапсуляция в действии (с)).
Если же у тебя все сценарии одинаковые, то написать обобщенный код тоже не rocket science, так что и с трудоемкостью проблем нет.

GZ>Таким образом, ты и связываешь разные места с контрактом ACLService.CanEdit.
А раньше они типа не были связаны, что ли?

GZ>Увеличиваешь cohesion.
Так этож хорошо.. Но на самом деле с когезией здесь ничего не происходит.

GZ>Ну наконец-то. Начинаю тебя понимать.
Похоже нет.

GZ>Со вторым ты вроде согласен. А вот первое, тебе покоя не дает. Несмотря на конкретный пример.
Конкретный пример показывает ровно обратное твоему утверждению, особенно если под ресурсоемкостью понимать стоимость дальнейшей поддержки, а не количество нажатий на клавиши для единоразового изменения логики CanEdit.

GZ>Это как раз чрезвычайно сильно изменяет модель относительно Rich.
Нет, не меняет.

GZ>Тады ACLService придется понимать с каким именно объектом он имеет дело.
Ровно в той же степени, что и для Rich.

GZ>Нет. Это может быть список объектов которые можно редактировать. А может быть и список идентификаторов объектов которые можно редактировать.
Из базы все равно приезжает список объектов, а не идентификаторов.

Здравствуйте, Mike Chaliy, Вы писали:

MC>То же что и в постах gandjustas,
Что конкретно?

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Хорошо приготовленная RDM в этом смысле превосходит ADM,
В этом смысле с хорошо приготовленной стройной моделью вообще мало что сравнится.

ЛИ>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
То есть, уже никто, ничего, никуда не сериализует?

ЛИ>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
Составляет и еще какую, вне зависимоти от инструментария. Когда обращение к одному полю в UI, совершенно "прозрачно" вызывает по цепочке серию обращений к БД для поднятия списка — это конкретная проблема.

ЛИ>3) а значит можно в полной мере использовать преимущества RDM;
Какие?

ЛИ>То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM
То есть, Rich == ORM?

ЛИ>P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно:
ЛИ>http://javatoday.ru/2009/03/rich-domain-model/

Прикладная логика, по определению, формулируется в терминах навигации по графу прикладных объектов и его изменении.

Это неверное определение, отсюда и неверные выводы в твоей статье..
А на кешировании, Lazy Loading-е и прочих продвинутых инструментах, облегчающих работу с жирной моделью — уже только ленивый не потоптался.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
IB>То есть, уже никто, ничего, никуда не сериализует?
Я выдилил что именно никто и никуда не сериалзирует .


ЛИ>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
IB>Составляет и еще какую, вне зависимоти от инструментария. Когда обращение к одному полю в UI, совершенно "прозрачно" вызывает по цепочке серию обращений к БД для поднятия списка — это конкретная проблема.

Ты сам отвечаеш на вопрос что именно мне не нравиться, вот например это не нравиться... Ну и откуда такие выводы? Сам придумал? У нас не бывает таких проблем.

Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються... Так что у нас небывает непредвиденных сайдеффектов. Типа УИ чето решило поменять, а отвалилось в датаслое.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Я выдилил что именно никто и никуда не сериалзирует .
То есть, бизнес-объекты никогда и никуда не сериализуются?

MC>Ты сам отвечаеш на вопрос что именно мне не нравиться, вот например это не нравиться...
Это вообще мало кому нравится, но это факт.

MC>Ну и откуда такие выводы? Сам придумал?
Нет, в жирной модели подсмотрел.

MC>Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються...
Кем и как? То есть, мало того, что в бизнес-объектах логика, так еще и вокруг накрутили, чтобы контролировать то, с чем бизнес-объект не справляется?

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Я выдилил что именно никто и никуда не сериалзирует .
IB>То есть, бизнес-объекты никогда и никуда не сериализуются?
У нас нет. Сериализация это такое же публичное АПИ. Для него есть контракты.

MC>>Ну и откуда такие выводы? Сам придумал?
IB>Нет, в жирной модели подсмотрел.
Смешно, ты подсматрел то чего нет. Тебе не кажеться что ситуация слегка глуповатая?

MC>>Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються...
IB>Кем и как?
Програмистом. Код то не секретарка пишет.

IB>То есть, мало того, что в бизнес-объектах логика, так еще и вокруг накрутили,
Опять дето подглядел? Плаин ПОКО. Ни маркировочных атрибтов, ничего. Тока чистые методы и состояние — рай.

IB> чтобы контролировать то, с чем бизнес-объект не справляется?
А че бизнес обьект должен думать об УИ? Мы на него таких респонсибилитей вообще не вешаем.

Здравствуйте, IB, Вы писали:

IB>

IB>Прикладная логика, по определению, формулируется в терминах навигации по графу прикладных объектов и его изменении.

IB>Это неверное определение, отсюда и неверные выводы в твоей статье..

Во-первых, это не определение, а следствие из определения. Во-вторых, отсюда в статье не может быть неверных выводов, потому что это последний абзац статьи

Здравствуйте, Sinix, Вы писали:


S>Не обижайтесь, но у вас какое-то идеализированное представление о проектировании систем — берём требования, реализуем и все щасливы. Нифига!
Это действительно так. Достаточно накаждом этапе (сбор требований-анализ-проектирование-реализация) подключать мозг.

S>Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
И что? Разве кто-то мешает изучать предметную область?

S>Во-вторых, требования заказчика не всегда бывают выполнимыми: их нужно прноверять.
Лушче всего это делать на этапе анализа.

S>В-третьих если вам потребуется взаимодействие с внешними системами, от вас потребуется громадная куча фич, которые очевидны из предметной области, но не указаны в требованиях.
См выше.

S>В-четвёртых у модели предметной области приоритет банально выше: она стабильнее, требования заказчика гарантированно не могут выйти за пределы предметной области (точнее, могут захватить другую предметную область, но это другой разговор) и, самое главное, правила предметной области не зависят от хотелок заказчика/проектировщика и тем самым делает предсказуемым процесс разработки.
И что? Типа сначала надо модель предментной области забабахать, а потом думать как с ней программу написать.
Это дурацкий подход мягко говоря. В первую очередь на что надо ориентироваться — требования, предметная область вносит дополнительные ограничения не более того.

G>>Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
G>>Я вообще склонен считать такие случаи паталогическими.
G>>Для поиска багов лучше тесты.

S>[ОФФТОП]
S>Про тесты: одно другого не отменяет. Лично мне куда проще саппортить такой код:
S>

S>void SomeMethod(string arg1, params int[] indexes)
S>{
S>  Code.NotNullOrEmpty(arg1, "arg1");
S>  Code.NotNull(indexes, "indexes");
S>  Code.GreaterThenOrEqual(indexes.Length, "indexes.Length", 5);
S>  Code.AssertState(CanDoSomeOperation, @"Some detailed exception message");

S>  // code goes here
S>}
S>

S>Сразу виден data contract + есть возможность отключать проверки по необходимости.
S>[/ОФФТОП]
Контракты — хорошо, только причем тут предметная область?

Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:

G>>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
MC>Никто не мешает совмещать.
Я говореи не об удобстве, а о необходимости. Необходимы на самом деле только проверки при сохранении, для удобства можно хоть на каждый чих делать.
Хотя удобство тоже разное бывает. См ниже.

MC>Простейшие проверки можно сделать в сеттерах — тогда они будут срабатывать еще и прямо при редактировании в гриде или прибинденных полях редактирования — что по моему скромному мнению есть очень удобно.
Совсем неудобно. Как сделать client-side проверки в вебе при засовывании их в сеттеры?

MC>Более сложные проверки можно вынести либо в метод Validate либо в какой-то ValidationService().
Когда есть фреймворк валидации, то делать проверки в сеттерах бессмысленно (дублирование кода).

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, IB, Вы писали:

MC>>>Могу и твоих фраз поискать про метод Сейв и тому подобное.
IB>>Что тебе в моих постах не нравится?

MC>То же что и в постах gandjustas, сорри, но вы оба не шарите в рич моделях , .

О горе нам, как же мы с этим жить будем
Я еще на делфях создавал насколько возможно rich модель, затрахался сильно

Здравствуйте, Mike Chaliy, Вы писали:

MC>У нас нет. Сериализация это такое же публичное АПИ. Для него есть контракты.
То есть, все таки сериализуется. Или все-таки нет? Ты не виляй ты прямо скажи.

MC>Смешно, ты подсматрел то чего нет. Тебе не кажеться что ситуация слегка глуповатая?
Меня эта ситуация пока что забавляет. С одной стороны у тебя все зашибись и проблем ты в упор не видишь, а с другой ничего конкретного сказать не можешь, на прямые вопросы не отвечаешь.
Вывод, в принципе очевиден, но словоблудие забавное.. =)

MC>Програмистом. Код то не секретарка пишет.
Какой код пишет программист?

MC>Опять дето подглядел?
У тебя вычитал..

MC> Плаин ПОКО. Ни маркировочных атрибтов, ничего. Тока чистые методы и состояние — рай.
Так как ты свои ПОКО сериализуешь?

MC>А че бизнес обьект должен думать об УИ?
Бизнес-объект вообще думать не должен.

MC>Мы на него таких респонсибилитей вообще не вешаем.
А какие вешаете?

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Во-первых, это не определение, а следствие из определения.
Если определение не верное, то следствие уж тем более.

ЛИ>Во-вторых, отсюда в статье не может быть неверных выводов, потому что это последний абзац статьи
Какая разница, какой это абзац, если это и есть ключевой момент твоей критики, остальное просто вода вокруг..

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Хотел бы подвергнуть сомнению все эти пункты:
ЛИ>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.


ЛИ>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.

Я бы архитектора выгнал сразу за такие слова.
Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.

ЛИ>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся.

ЛИ>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
Покажите пример кода, где по rich гораздо удобнее anemic.

Здравствуйте, gandjustas, Вы писали:

S>>Не обижайтесь, но у вас какое-то идеализированное представление о проектировании систем — берём требования, реализуем и все щасливы. Нифига!
G>Это действительно так. Достаточно накаждом этапе (сбор требований-анализ-проектирование-реализация) подключать мозг.

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

Я вам привёл самый обычный пример про невозможность проверок в 1 месте.
До примера вы писали

Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям

после:

Все что написано сильно зависит от предметной области и желаний заказчика.

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

---

S>>Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
G>И что? Разве кто-то мешает изучать предметную область?
G>Лушче всего это делать на этапе анализа.

Ещё раз прошу — почитайте Эванса. Он классно расписал чем плох формальный подход к предметной области (и про анализ там тоже написано.) Ещё такое ощущение, что у вас разработка заканчивается с впариванием результатов заказчику — там такой подход конеш рулит.

S>>В-третьих если вам потребуется взаимодействие с внешними системами, от вас потребуется громадная куча фич, которые очевидны из предметной области, но не указаны в требованиях.
G>Лушче всего это делать на этапе анализа.
...
G>И что? Типа сначала надо модель предментной области забабахать, а потом думать как с ней программу написать.
G>Это дурацкий подход мягко говоря. В первую очередь на что надо ориентироваться — требования, предметная область вносит дополнительные ограничения не более того.

А вот здесь вы вообще неправы. Основное проектирование систенмы делается (если делается вообще) на первых итерациях.
А все проблемы о которых я говорю появляются позже, когда система уже сдана и эксплуатируется. И вот тогда вы огребаете проблем по-полной, потому что любой минорный фикс убивет к [censored] весь дизайн. Потому то вы поверили в достаточность требований, которые заведомо не содержат полной информации. Не люблю я подход "сделал как просили". Хреново смотрится когда ты получил деньги, а потом выставляешь заказчика идиотом.

Скажите, как вообще можно строить дизайн системы на основе функциональных требований? Они же описывают только внешний интерфейс системы. Всё что вы можете сделать — провести кластеризацию графа зависимостей и выделить компоненты по степени связности. Этот дизайн нифига не будет стабильным — любое новое требование перекроит все зависимости и дизайн, заточенный под конкретный набор юз-кейзов будет только мешать развивать систему.

Блин, я не знаю, как объяснять очевидные вещи... понимаете, модель предметной области — это не структура данных, не куча бумажек, и уж тем более не отчёт аналитика. Это грубо говоря общая модель, которая используется всеми и позволяет общаться на одном языке с неспециалистами, легко проверять корректность требований и предвидеть что потребуется дальше. Ну и в подарок получаете дизайн устойчивый к самым неожиданным требованиям.

Естественно, сразу строить _полную_ модель предметной области будет только полный идиот — т.к. штука в принципе бесконечная. Но использовать модель надо с самого начала проекта и не отступать от этого использования (опять было написано у Эванса). Поэтому ваши утверждения что "модель лучше использовать на этапе анализа" смотрятся весьма странно.

---

G>>>Для поиска багов лучше тесты.
S>>[ОФФТОП]
S>>Про тесты: одно другого не отменяет. Лично мне куда проще саппортить такой код:
S>>[/ОФФТОП]
G>Контракты — хорошо, только причем тут предметная область?

А почитайте всю цепочку — здесь предметная область не обсуждалась никак.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>Я вам привёл самый обычный пример про невозможность проверок в 1 месте.
S>До примера вы писали
S>

S>Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям

S>после:
S>

S>Все что написано сильно зависит от предметной области и желаний заказчика.

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

S>

---

S>>>Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
G>>И что? Разве кто-то мешает изучать предметную область?
G>>Лушче всего это делать на этапе анализа.

S>Ещё раз прошу — почитайте Эванса. Он классно расписал чем плох формальный подход к предметной области (и про анализ там тоже написано.)
Я его читал. Я предлагаю не рассматривать"предметную область" как вещь в себе.
Ведь в конченом итоге надо сделать приложение, которое полезно людям, а не модель некоторой предметной области.

S>Ещё такое ощущение, что у вас разработка заканчивается с впариванием результатов заказчику — там такой подход конеш рулит.
Не совсем "впариваением", но смысл именно такой — чтобы заказчик был доволен.

S>А все проблемы о которых я говорю появляются позже, когда система уже сдана и эксплуатируется. И вот тогда вы огребаете проблем по-полной, потому что любой минорный фикс убивет к [censored] весь дизайн. Потому то вы поверили в достаточность требований, которые заведомо не содержат полной информации. Не люблю я подход "сделал как просили". Хреново смотрится когда ты получил деньги, а потом выставляешь заказчика идиотом.
Это зависит от закачика и от менеджера.
Есть люди которые понимают, то рекая программа пишется раз и навсегда, что любая неучнеттая мелочь может оказаться критической.
Если заказчик и менеджер это понимаю, то получаются хорошие программы. (хотя если менеджер не понимает, то его уволить надо)
А бывают заказчики, которые хотят побыстрее, подешевле и побольше. С такимми действительно лучше работать по принципу "сделали как просили".

S>Скажите, как вообще можно строить дизайн системы на основе функциональных требований?
Рецепты давно известны: слабая связность и следовать принципам KISS и YAGNI.

S>Они же описывают только внешний интерфейс системы. Всё что вы можете сделать — провести кластеризацию графа зависимостей и выделить компоненты по степени связности. Этот дизайн нифига не будет стабильным — любое новое требование перекроит все зависимости и дизайн, заточенный под конкретный набор юз-кейзов будет только мешать развивать систему.
Далеко не так. Ведь у нас есть не только пожелания заказчика, а есть еще и требования от предметной области.
Стартовый набор требований обычно достаточно большой, чтобы большая часть системы оставалась стабильной при всех изменениях.

S>Блин, я не знаю, как объяснять очевидные вещи... понимаете, модель предметной области — это не структура данных, не куча бумажек, и уж тем более не отчёт аналитика. Это грубо говоря общая модель, которая используется всеми и позволяет общаться на одном языке с неспециалистами, легко проверять корректность требований и предвидеть что потребуется дальше.
Угу Ubiquitous Language, проходили уже. А толку от него? Ну поговорили вы со специалистами на их языке, сделали требования корректныим.
Как это на дизайн приложения повлияет.

S>Ну и в подарок получаете дизайн устойчивый к самым неожиданным требованиям.
Если бы все было так хорошо, как на словах, то все бы давно использовали DDD.
Вот только DDD начинает отсасывать даже тогда, когда просто требуется добавить нетривиальную экранную форму для каких-либо целей.

S>Естественно, сразу строить _полную_ модель предметной области будет только полный идиот — т.к. штука в принципе бесконечная. Но использовать модель надо с самого начала проекта и не отступать от этого использования (опять было написано у Эванса). Поэтому ваши утверждения что "модель лучше использовать на этапе анализа" смотрятся весьма странно.
Вот становится весело, когда новые требования не укладываются в модель.
Например была какая-то банальная торговая система, а тут потребовалось внести возможность резервирования и предзаказа.

ЗЫ. Чем больше кода у вас написано и чем большей степенью свзяности он обладает, тем тяжелее вносить изменения.
Заранее всех изменений не предугадаешь, лучше писать меньше кода и оставлять больше точек расширения.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>У нас нет. Сериализация это такое же публичное АПИ. Для него есть контракты.
IB>То есть, все таки сериализуется. Или все-таки нет? Ты не виляй ты прямо скажи.
Нет не сереализируеться.

MC>>Смешно, ты подсматрел то чего нет. Тебе не кажеться что ситуация слегка глуповатая?
IB>Меня эта ситуация пока что забавляет. С одной стороны у тебя все зашибись и проблем ты в упор не видишь, а с другой ничего конкретного сказать не можешь, на прямые вопросы не отвечаешь.
IB>Вывод, в принципе очевиден, но словоблудие забавное.. =)
Конкретное что? Я на любой конкретный вопрос по теме могу ответить. Я практикующий програмист.

MC>> Плаин ПОКО. Ни маркировочных атрибтов, ничего. Тока чистые методы и состояние — рай.
IB>Так как ты свои ПОКО сериализуешь?
Я их НЕ сериализирую.

MC>>Мы на него таких респонсибилитей вообще не вешаем.
IB>А какие вешаете?
Реализацию языка доменной модели.

Здравствуйте, gandjustas, Вы писали:

ЛИ>>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
G>Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.
Если не секрет, вам во сколько становилось в цифрах? Имхо без конкретного примера это только разговоры.

ЛИ>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
G>Я бы архитектора выгнал сразу за такие слова.
G>Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.
Имхо вы долбанетесь переделывать его в веб с сохранением архитектуры. Вы как-то раньше сами жаловались на это. Кроме того, бизнес-объекты даже в случае миграции в сторону web-клиента не передаются в UI -- там используются DTO, поэтому ничто не мешает бизнес-объектам быть rich; наоборот, часто это даже удобно.

ЛИ>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
G>Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся.
Речь об одном _физическом_ звене.

G>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>Покажите пример кода, где по rich гораздо удобнее anemic.

Легко: ActiveRecord вам в руки. Для небольших проектов ну просто супер. Поюзайте ActiveWriter для простенького сайта или магазина, поймете, о чем я.
Только не надо заводить разговор о том, что Active Record -- это антипаттерн, потому что так кому-то приснилось.

Извините, если резко.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Нет не сереализируеться.
Ну, вы ребята тогда в какой-то альтернативной реальности живете, где объекты посредством страшного колдунства сами оказываются в базе, во внешнем файле, на другом сервере. Тут да, тут жирная модель возможно работает.. )

MC> Я на любой конкретный вопрос по теме могу ответить. Я практикующий програмист.
Пока не видно..

MC>Я их НЕ сериализирую.
Как они у тебя в базе оказываются?

MC>Реализацию языка доменной модели.
"С точки зрения банальной эрудиции, не каждый индивидуум способено лояльно игнорировать тенденции..." далее по тексту.
Спорим я больше умных слов знаю? Реализация — это не ответственность.

Здравствуйте, gandjustas, Вы писали:

ЛИ>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
G>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>Покажите пример кода, где по rich гораздо удобнее anemic.

Вот можем начать с этого.

Rich

public void CreateOrder(number){
  var order = _orderFactory.Create(number);

  order.AddItem(product1, weight);
  order.AddItem(product2, weight);

  _orderRepository.Add(order);
}

Anemic

public void CreateOrder(number){
  validateOrderNumber(number);
  var total = calcualteTotal(weight1, weight2);
  validateIfTotalAcceptable(total);

  var order = new Order(){Number = number, Total = total};
  var item1 = new Item(){OrderId = order.Id, ProductId = product1.Id, Weight = weight1};
  var item2 = new Item(){OrderId = order.Id, ProductId = product2.Id, Weight = weight2};

  _orderDAL.InsertOrder(order);
  _orderDAL.InsertOrderItem(item1);
  _orderDAL.InsertOrderItem(item2);
}

Здравствуйте, meowth, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
G>>Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.
M>Если не секрет, вам во сколько становилось в цифрах? Имхо без конкретного примера это только разговоры.
В цифрах не могу, нету примера с жирной моделью и аналогичной ей стройной, чтобы сравнить.
Первое на что можно обратить внимание — необходимость согласовывать изменения в DTO и доменных объектах.
Второе — достачно сложное создание произвольных выборок.

ЛИ>>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
G>>Я бы архитектора выгнал сразу за такие слова.
G>>Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.
M>Имхо вы долбанетесь переделывать его в веб с сохранением архитектуры.
Дык в том задача архитектора, чтобы не долбанулись программисты.

M>Вы как-то раньше сами жаловались на это.
Нет. Я говорил что тупо написанное десктом приложение в веб переделать практически невозможно.
Если такой вариант возможен, то прилождение надо писать умно.

Как раз сейчас наблюдаю массовый переход на веб, тех кто еще год назад даже не думал о таком.

M>Кроме того, бизнес-объекты даже в случае миграции в сторону web-клиента не передаются в UI -- там используются DTO, поэтому ничто не мешает бизнес-объектам быть rich; наоборот, часто это даже удобно.
Ну это у кого как.
У меня примерно на 60% вьюх передаются Presentation Entity, а в остальных вполне хватает тех самых объектов, вытащенных из базы.
Причем часто Presentation Entity состоит из нескольких объектов, вытащенных из базы.

ЛИ>>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
G>>Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся.
M>Речь об одном _физическом_ звене.
Да, что-то промазал.

G>>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>>Покажите пример кода, где по rich гораздо удобнее anemic.

M>Легко: ActiveRecord вам в руки. Для небольших проектов ну просто супер. Поюзайте ActiveWriter для простенького сайта или магазина, поймете, о чем я.
Я как-то юзал ActiveRecord как раз для сайта, не заметил чтобы кода стало значительно меньше.
Кроме того все те же прооблемы с произвольными выборками.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Нет не сереализируеться.
IB>Ну, вы ребята тогда в какой-то альтернативной реальности живете, где объекты посредством страшного колдунства сами оказываются в базе, во внешнем файле, на другом сервере. Тут да, тут жирная модель возможно работает.. )
Мы в базу данных ничего не сереализируем. Туда наши обьекты мапяться. Для нас это делает тулинг(инфраструктура), например для базы данных это ОРМ тулы.
На другом сервере наши обьекты не оказываються. Там оказываються ДТО. Для ДТО у нас тоже есть тулинг типа AutoMapper.

MC>>Реализацию языка доменной модели.
IB>"С точки зрения банальной эрудиции, не каждый индивидуум способено лояльно игнорировать тенденции..." далее по тексту.
IB>Спорим я больше умных слов знаю? Реализация — это не ответственность.

Я же говорю читать надо, как я тебе еще могу сказать. Это стандарное понятиие в ДДД которое хрен оспориш. Если я тебе начну по-полочкам раскладывать ты опять отять буш выдергивать все из контекста и придираться к словам.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, meowth, Вы писали:

M>>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
G>>>Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.
M>>Если не секрет, вам во сколько становилось в цифрах? Имхо без конкретного примера это только разговоры.
G>В цифрах не могу, нету примера с жирной моделью и аналогичной ей стройной, чтобы сравнить.
G>Первое на что можно обратить внимание — необходимость согласовывать изменения в DTO и доменных объектах.
Мы этим гордимся, у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере. А все потому что DTO полностью развязаны. С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.

G>Второе — достачно сложное создание произвольных выборок.
Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.

Предположим что есть.
class Product{
}
class Image{
ProductId;
}
Для того чтобы получить флатен презентацию так или иначе придеться вводить промежуточное ДТО

ProductListItem{
Name
ImageSize,
ImageUrl
}

Решение и для рич моделей и для анмемичных идентичное.

Здравствуйте, IB, Вы писали:

IB>Ну, вы ребята тогда в какой-то альтернативной реальности живете, где объекты посредством страшного колдунства сами оказываются в базе, во внешнем файле, на другом сервере. Тут да, тут жирная модель возможно работает.. )

А в анемеичной модели с помощью колдовства сериализованные стандартными сериализатором объекты отлично понимают обработчики внешних файлов и другие сервера? Что с этими серверами становится при изменении модели?

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
G>>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>>Покажите пример кода, где по rich гораздо удобнее anemic.

MC>Вот можем начать с этого.

MC>Rich
MC>

MC>public void CreateOrder(number){
MC>  var order = _orderFactory.Create(number);

MC>  order.AddItem(product1, weight);
MC>  order.AddItem(product2, weight);

MC>  _orderRepository.Add(order);
MC>}
MC>

Ага, еще код AddItem покажи, и валидации.
Кстати в какой момент она выполняется?

MC>Anemic
MC>

MC>public void CreateOrder(number){
MC>  validateOrderNumber(number);
MC>  var total = calcualteTotal(weight1, weight2);
MC>  validateIfTotalAcceptable(total);

MC>  var order = new Order(){Number = number, Total = total};
MC>  var item1 = new Item(){OrderId = order.Id, ProductId = product1.Id, Weight = weight1};
MC>  var item2 = new Item(){OrderId = order.Id, ProductId = product2.Id, Weight = weight2};

MC>  _orderDAL.InsertOrder(order);
MC>  _orderDAL.InsertOrderItem(item1);
MC>  _orderDAL.InsertOrderItem(item2);
MC>}
MC>

Наверное имелось ввиду

public void CreateOrder(number)
{
  var order = new Order(){Number = number, Total = calcualteTotal(weight1, weight2)};
  var item1 = new Item(){Order = order, Product = product1, Weight = weight1};
  var item2 = new Item(){Order = order, Product = product2, Weight = weight2};

  _validationService.Validate(order);
  _orderRepository.Add(order);
}

А вообще на лице денормализация. Надо бы еще объяснить зачем она нужна и почему бы не поддерживать целостность триггерами в БД, если денормализация нужна.

Кстати, что здесь Order.Total? Почему мы total проверяем при сохранении, а не там где действительно надо (при отправке например)?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
G>>>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>>>Покажите пример кода, где по rich гораздо удобнее anemic.

MC>>Вот можем начать с этого.

MC>>Rich
MC>>

MC>>public void CreateOrder(number){
MC>>  var order = _orderFactory.Create(number);

MC>>  order.AddItem(product1, weight);
MC>>  order.AddItem(product2, weight);

MC>>  _orderRepository.Add(order);
MC>>}
MC>>

G>Ага, еще код AddItem покажи, и валидации.
G>Кстати в какой момент она выполняется?

Зачем, ты же просил где лушче. Так вот за счет того что у нас есть енкапсуляция, код бизнес процесов получаеться максимально читабельным.

MC>>Anemic
MC>>

MC>>public void CreateOrder(number){
MC>>  validateOrderNumber(number);
MC>>  var total = calcualteTotal(weight1, weight2);
MC>>  validateIfTotalAcceptable(total);

MC>>  var order = new Order(){Number = number, Total = total};
MC>>  var item1 = new Item(){OrderId = order.Id, ProductId = product1.Id, Weight = weight1};
MC>>  var item2 = new Item(){OrderId = order.Id, ProductId = product2.Id, Weight = weight2};

MC>>  _orderDAL.InsertOrder(order);
MC>>  _orderDAL.InsertOrderItem(item1);
MC>>  _orderDAL.InsertOrderItem(item2);
MC>>}
MC>>

G>Наверное имелось ввиду
G>

G>public void CreateOrder(number)
G>{
G>  var order = new Order(){Number = number, Total = calcualteTotal(weight1, weight2)};
G>  var item1 = new Item(){Order = order, Product = product1, Weight = weight1};
G>  var item2 = new Item(){Order = order, Product = product2, Weight = weight2};

G>  _validationService.Validate(order);
G>  _orderRepository.Add(order);
G>}
G>

нет мелось ввиду то что имелось,

1) ты отпарвил валидацию в конец, должно быть в начале, иначе возможны колизии, принцип фаил фаст знаеш? Обьяснить почему это проблема?
2) ты поубирал ИД поля. Но вы же с ИБ орете что вам надо Order — Item для одного отдела, TradingPeriod — Item для другого. Как же это вы свзянанные обьекты сможете представить для двух отделов. Как вы сможете собрать из этого ДТО для веб сервиса, если оно все в коде зареференшено.
3) ты поубирал ИД поля. Это обозначает что у вас юзаеться ОРМ и тоже может юзаться лейзи лоад.
4) ты нарушил СРП в вашем понимании, обьекты теперь хранят не тока данные обьекта, но и ссылки на другие обьекты.

G>А вообще на лице денормализация. Надо бы еще объяснить зачем она нужна и почему бы не поддерживать целостность триггерами в БД, если денормализация нужна.
Ты конкретней, ты где нашел денормализацию?

Ты про Тотал? Почитай про архитектуры финансовых систем. Там никогда агрегатные результаты не считаються динамически. Если один раз ордер продался по цене 20.00089 денег, то даже когда поменяеються требования к округлению он всеравно должно остаться 20.00089.
Плюс номрализация Тотала не потдаеться юнит тестированию.

G>Кстати, что здесь Order.Total? Почему мы total проверяем при сохранении, а не там где действительно надо (при отправке например)?

Потому что это бизнес процес который считает тотал. И этот же бизнес процес должен сказать если там что-то не так. Отправка это вообще не контекстаная операция. Нафига мне валидировать тотал если он уже посчитан и дефакто валидный?

В любом случае твой пример всеравно не читабельный. Попробуй его прочесть плаин текстом. Куча дублирования и мусора.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Мы в базу данных ничего не сереализируем.
А что же вы в нее, простите, делаете?

MC>Туда наши обьекты мапяться.
В чем отличие знаешь?

MC> Для нас это делает тулинг(инфраструктура), например для базы данных это ОРМ тулы.
Как именно?

MC>На другом сервере наши обьекты не оказываються. Там оказываються ДТО. Для ДТО у нас тоже есть тулинг типа AutoMapper.
Как этот DTO получается из объекта?

MC> Это стандарное понятиие в ДДД которое хрен оспориш.
Если бы ты еще понятия к месту формулировал, бы ло бы вообще замечательно.

MC> Если я тебе начну по-полочкам раскладывать ты опять отять буш выдергивать все из контекста и придираться к словам.
Где я к словам придирался? Ты еще ни на один вопрос внятно не ответил...

Здравствуйте, Ziaw, Вы писали:

Z>А в анемеичной модели с помощью колдовства сериализованные стандартными сериализатором объекты отлично понимают обработчики внешних файлов и другие сервера?
Это ты к чему?

Z> Что с этими серверами становится при изменении модели?
Ты о чем?

Здравствуйте, Mike Chaliy, Вы писали:

MC>Мы этим гордимся,
Тем, что при изменении нужно поменять в четырех местах, а не в двух? Молодцы! =)

MC>у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере.
Легко у вас такая ситуация бывает — в модели поле удалили, а в DTO забыли, а у клиента на это поле была критичная логика завязана. В запросе пришел NULL — клиент лег.

MC>С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.
Просто признайтесь, что вы любите двойную работу.

MC>Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.
Для тебя это возможно будет новостью, но 95% задач современного приложения — это репортинг.
Отсюда делаем вывод о применимости жирной модели.

MC>Решение и для рич моделей и для анмемичных идентичное.
Когда есть LINQ необходимость в промежуточных DTO отпадает, можно все по месту построить, для стройной модели, разумеется.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, meowth, Вы писали:

M>>>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>>>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
G>>>>Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.
M>>>Если не секрет, вам во сколько становилось в цифрах? Имхо без конкретного примера это только разговоры.
G>>В цифрах не могу, нету примера с жирной моделью и аналогичной ей стройной, чтобы сравнить.
G>>Первое на что можно обратить внимание — необходимость согласовывать изменения в DTO и доменных объектах.
MC>Мы этим гордимся, у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере. А все потому что DTO полностью развязаны. С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.

Ведь гораздо легче вообще не иметь такой синхронизации.

G>>Второе — достачно сложное создание произвольных выборок.
MC>Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.

Почему такая хорошая DDD заставляет выделять отдельное понятие репортинга? (на деле — любое отображение информации)

MC>Предположим что есть.
MC>class Product{
MC>}
MC>class Image{
MC> ProductId;
MC>}
MC>Для того чтобы получить флатен презентацию так или иначе придеться вводить промежуточное ДТО

MC>ProductListItem{
MC> Name
MC> ImageSize,
MC> ImageUrl
MC>}
Суть не в DTO, а в способах его получения.

MC>Решение и для рич моделей и для анмемичных идентичное.
Ну покажи полное решение для такого случая в rich, учитывая что надо получать далеко не все все товары, там есть пейджинг, видимость, выборка по категории итп. Для каждого товара существует куча картинок и надо получить первую.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Так вот за счет того что у нас есть енкапсуляция, код бизнес процесов получаеться максимально читабельным.
Код бизнес-процессов, за счет такой "енкапсуляции" получается малопредсказуемым и неочевидным.

MC>нет мелось ввиду то что имелось,
Тогда ты непонятно с чем споришь..

MC>В любом случае твой пример всеравно не читабельный.
Он гораздо понятнее чем твой.. )

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>> Для нас это делает тулинг(инфраструктура), например для базы данных это ОРМ тулы.
IB>Как именно?

_productRepository.Add(product);

Тебя интересует как работает Add это к ОРМ тулу твоего выбора. В НХибирнейт это Session.Save(obj);

MC>>На другом сервере наши обьекты не оказываються. Там оказываються ДТО. Для ДТО у нас тоже есть тулинг типа AutoMapper.
IB>Как этот DTO получается из объекта?

ProductDTO dto = Mapper.Map(product);

Тебя интересует как работает Mapэто к мапперу твоего выбора.

MC>> Это стандарное понятиие в ДДД которое хрен оспориш.
IB>Если бы ты еще понятия к месту формулировал, бы ло бы вообще замечательно.

И что там не к месту? Именно реализация этого языка это и есть респонсибилити. Хранит данные, не хранит, реализованно это методами или чем-то другим — это детали реализации. А респонсибилити это реалзиация языка.
Нарпимер для респонсибилити обьекта ордер это реализация языка по работе с оредорм. Например: Вычиление Тотала, Добовление айтемов, Маркировка временных айтемов, Преход в состояние А.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, IB, Вы писали:

IB>>Ну, вы ребята тогда в какой-то альтернативной реальности живете, где объекты посредством страшного колдунства сами оказываются в базе, во внешнем файле, на другом сервере. Тут да, тут жирная модель возможно работает.. )

Z>А в анемеичной модели с помощью колдовства сериализованные стандартными сериализатором объекты отлично понимают обработчики внешних файлов и другие сервера? Что с этими серверами становится при изменении модели?

Я уже спрашивал. Он считает что при изменении модели, публичный АПИ тоже должен поменяться .

Для них вообще поменять модель это что-то екстраординарное, обычно связанное с изменением модели данных, публичных АПИ, интерфесов пользователя и тому подобному...

Им не понять что такое поменять диометрально релейшеншип сущьностей и при этом не поменять ни хранилище и все вокруг .

Здравствуйте, IB, Вы писали:

IB>Инструмент — это инкапсуляция, и есть метрика правильности его применения.
Ну наконец — то.

GZ>>+-1 Только тогда это будет аналог Rich.
IB>Нет. Самый близкий аналог Rich — это третий способ.
Вот ну офигенно оригинально. Разговор умного с суперумным.
— Модель плохая.
— Почему плохая? Вот же хорошее решение?
— Нет это не хорошее решение, потому что есть решение плохое.
— Почему нужно выбирать плохое решение?
— Потому что модель плохая, и для нее надо выбирать плохое решение.
Ну и что тут обсуждать?

GZ>>Только значительно хуже. Ибо в Rich, можно спрятать дополнительную информацию за интерфейсом и загружать по мере надобности.
IB>Значительно лучше. Это не дополнительная информация, это всегда необходимая информация.
Это аггрегируемая информация. Ибо на физическом уровне, доступ управляется набором идентификаторов связанных с объектом. Для того, чтобы получить реальный ACL — нужно ее просчитать по контексту пользователя и по объекту. По каждому чиху просчитывать информацию? Гениальное решение. Предлагаю занести в аналы природы. А если еще учесть что в экспорте/импорте этой информация вообще не нужна.
IB>Никто не собирается грузить родителя сразу, необходимая информация уже есть в дочернем, он самодостаточен, ему ничего не нужно.
IB>Причем эта информация не является лишней, она необходима при каждой проверке доступа (и наверняка не только доступа, раз доступ на нее завязан).
Ты читаешь что я пишу?

GZ>>+1 Но проблема, что это надо передавать каждый раз в разных сценариях.
IB>Это не проблема. Это как раз хорошо. Я явно в каждом сценарии понимаю, что нужно и явно это передаю.
Зачем???? Вот зачем тебе помнить чтобы солнце взошло, тебе нужно поднять сначало левый тумблем, а потом правый? Не проще ли на самом солнце кликнуть и не разбираться с проблемами бытия, орбит, и магнитных бурь.

IB>Причем забыть и не передать, я не могу — компилятор поправит.
Не поправит. У тебя интерфейс не изменяется, а только дополняется.
IB>И явно передавая — четко понимаешь чего это стоит в каждом сценарии и каждый сценарий, при необходимости, ты можешь настроить отдельно, не трогая другие (например, в одном случае получая нужный объект из кеша, а в другом напрямую в обход всего, если это критично — инкапсуляция в действии (с)).
А вот зачем? Весь смысл Rich, это то что ты абстрагируешься от БД. Хочешь накормить кошку, просто дай ей еды. Ежели хочешь помнить о том чтобы кишочках все это переваривалось, то даже преждевременное вскрытие тебе не поможет. Ты об этом узнаешь только постфактум, когда кал из кошки пойдет. Точно также и в больших приложениях. Пока реальных данных нет, ты не можешь сказать что оно работает с той, или иной степенью эффективности.

GZ>>Таким образом, ты и связываешь разные места с контрактом ACLService.CanEdit.
IB>А раньше они типа не были связаны, что ли?
Нет. В Rich — все места связаны с методом объекта. Объект и контекст пользователя, все что нужно для пользы дела. Все остальные проблемы, как зависимость от типа, можно решить в одном конкретном месте.

GZ>>Увеличиваешь cohesion.
IB>Так этож хорошо.. Но на самом деле с когезией здесь ничего не происходит.
Звиняюсь, coupling.

GZ>>Со вторым ты вроде согласен. А вот первое, тебе покоя не дает. Несмотря на конкретный пример.
IB>Конкретный пример показывает ровно обратное твоему утверждению, особенно если под ресурсоемкостью понимать стоимость дальнейшей поддержки, а не количество нажатий на клавиши для единоразового изменения логики CanEdit.
То, что можно изменить полиморфно поведение в одном месте существенно увеличивает поддержку? Абсолютно согласен. Ваще вопросов не возникает.

GZ>>Тады ACLService придется понимать с каким именно объектом он имеет дело.
IB>Ровно в той же степени, что и для Rich.
В Rich — строго наоборот. Объект решает как ему проверяться. Это большая разница.

GZ>>Нет. Это может быть список объектов которые можно редактировать. А может быть и список идентификаторов объектов которые можно редактировать.
IB>Из базы все равно приезжает список объектов, а не идентификаторов.
С чего ты решил?

Здравствуйте, gandjustas и IB, Вы писали:

Нет, ребят, вы честно жжоте

Человек (Mike Chaliy) показывает вам на примере своего проекта, как оно работает -- что оно а)элегантно б)реально РАБОТАЕТ (это тоже важно) б)легко сопровождаемо в)не содержит тех проблем, которые вы пытаетесь отыскать в решении.

А вы по-прежнему продолжаете доказывать, что его решение плохое и полнится косяками и костылями -- не этими, так теми. Но при этом почему-то сами ставите ему вопрос, сами отвечаете, и в своем ответе находите недочеты, которые приписываете решению.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Мы этим гордимся,
IB>Тем, что при изменении нужно поменять в четырех местах, а не в двух? Молодцы! =)
Нам надо менять тока в том месте где надо.
1) Поменлась бизнес логика поменяли в моделе
2) Поменялся публичный АПИ, поменяли в ДТО
3) Потребовалось перелаяутить хранилище, со скрипом но и это сделали.

MC>>у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере.
IB>Легко у вас такая ситуация бывает — в модели поле удалили, а в DTO забыли, а у клиента на это поле была критичная логика завязана. В запросе пришел NULL — клиент лег.
Ну и кто дурак? У нас такого не быват. У нас публичный АПИ тестируеться.

MC>>С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.
IB>Просто признайтесь, что вы любите двойную работу.


MC>>Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.
IB>Для тебя это возможно будет новостью, но 95% задач современного приложения — это репортинг.
IB>Отсюда делаем вывод о применимости жирной модели.
Для меня это вообще не новость, у нас репортинг это инфраструктура к которой модель вообще не имеет отношения.
Обычно выбираеться из нескольких вариантов.
1) Для репортинга похожего по структуре на доменную модель, данные беруться из тех же маппингов что и доменная модель.
2) Для более сложного репортинга делаем свои маппинги.
3) Для совсем сложного пишем кастомный код.

Так как результатом репорта всерано являеться ДТО, то не изменение реализации, не изменение модели никак на результат не влияет, соотвевено клиенты живут себе долго и щасливо.

Если тебе хочеться сказать что типа ваша модель покрывает 5% кода приложения, а вот наша анемичная 95%(мне кажеться 40%), я с тобой вполне согласен. Для нас это не являеться камнем претконовения. Все ДТО у нас анемичны по определению.

MC>>Решение и для рич моделей и для анмемичных идентичное.
IB>Когда есть LINQ необходимость в промежуточных DTO отпадает, можно все по месту построить, для стройной модели, разумеется.
LINQ никто не отменял, с чего ты взял что мы не используем LINQ? У нас куча траверсинга на LINQ, репорты тож на LINQ...

Здравствуйте, gandjustas, Вы писали:


MC>>Мы этим гордимся, у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере. А все потому что DTO полностью развязаны. С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.
G>
G>Ведь гораздо легче вообще не иметь такой синхронизации.
Гм, чем легче? Прототип набрасать да легче, а для потдерживаемого приложения вложения в эту синхронизацию не составляють и тысячных долей проекта....

G>>>Второе — достачно сложное создание произвольных выборок.
MC>>Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.
G>
G>Почему такая хорошая DDD заставляет выделять отдельное понятие репортинга? (на деле — любое отображение информации)
Ым, потому что у нее респонсибилити другая... У репортинга своя, у модели другая...

G>Суть не в DTO, а в способах его получения.
И чем они отличаються? Если ты думаеш что мы пользуемся чем то секретным ты ошибаешся, все на виду...

MC>>Решение и для рич моделей и для анмемичных идентичное.
G>Ну покажи полное решение для такого случая в rich, учитывая что надо получать далеко не все все товары, там есть пейджинг, видимость, выборка по категории итп. Для каждого товара существует куча картинок и надо получить первую.

 (from p in Query() // Query возвращет IQueryable<Product>
        where p.Category.Contains("sdfsdf")
        select new ProductListItem(){
          Name = p.Name; 
          ImageUrl = p.Images.First().Url
        }).Take(10).ToList();

Чето типа того, писал прямо тут, могут быть ошибки.
В реальной реализации пейджинг, сортинг, фильтры находятсья в инфраструктуре.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Так вот за счет того что у нас есть енкапсуляция, код бизнес процесов получаеться максимально читабельным.
IB>Код бизнес-процессов, за счет такой "енкапсуляции" получается малопредсказуемым и неочевидным.

И что там не очевидного? И что ты не можеш предсказать?

MC>>нет мелось ввиду то что имелось,
IB>Тогда ты непонятно с чем споришь..
MC>>В любом случае твой пример всеравно не читабельный.
IB>Он гораздо понятнее чем твой.. )

Сделал код более или мение читаебльным убрав необходимые фитчи, прикольно.

Так еще более читабельней... И респонсибилити ясна.

public CreateOrder(number){
}

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Mike Chaliy, Вы писали:

MC>>>Здравствуйте, gandjustas, Вы писали:

ЛИ>>>>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
G>>>>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
G>>>>Покажите пример кода, где по rich гораздо удобнее anemic.

MC>>>Вот можем начать с этого.

MC>>>Rich
MC>>>

MC>>>public void CreateOrder(number){
MC>>>  var order = _orderFactory.Create(number);

MC>>>  order.AddItem(product1, weight);
MC>>>  order.AddItem(product2, weight);

MC>>>  _orderRepository.Add(order);
MC>>>}
MC>>>

G>>Ага, еще код AddItem покажи, и валидации.
G>>Кстати в какой момент она выполняется?

MC>Зачем, ты же просил где лушче. Так вот за счет того что у нас есть енкапсуляция, код бизнес процесов получаеться максимально читабельным.

MC>>>Anemic
MC>>>

MC>>>public void CreateOrder(number){
MC>>>  validateOrderNumber(number);
MC>>>  var total = calcualteTotal(weight1, weight2);
MC>>>  validateIfTotalAcceptable(total);

MC>>>  var order = new Order(){Number = number, Total = total};
MC>>>  var item1 = new Item(){OrderId = order.Id, ProductId = product1.Id, Weight = weight1};
MC>>>  var item2 = new Item(){OrderId = order.Id, ProductId = product2.Id, Weight = weight2};

MC>>>  _orderDAL.InsertOrder(order);
MC>>>  _orderDAL.InsertOrderItem(item1);
MC>>>  _orderDAL.InsertOrderItem(item2);
MC>>>}
MC>>>

G>>Наверное имелось ввиду
G>>

G>>public void CreateOrder(number)
G>>{
G>>  var order = new Order(){Number = number, Total = calcualteTotal(weight1, weight2)};
G>>  var item1 = new Item(){Order = order, Product = product1, Weight = weight1};
G>>  var item2 = new Item(){Order = order, Product = product2, Weight = weight2};

G>>  _validationService.Validate(order);
G>>  _orderRepository.Add(order);
G>>}
G>>

MC>нет мелось ввиду то что имелось,
Тогда только могу констатировать факт что ты не умеешь рабоать со стройной моделью.

MC>1) ты отпарвил валидацию в конец, должно быть в начале, иначе возможны колизии, принцип фаил фаст знаеш? Обьяснить почему это проблема?
Ну попробуй объясни. У меня нету ни одной тяжелой операции, которая вызывается неявно. А наносекнуды, затраченные на создания объектов роли не играют.

MC>2) ты поубирал ИД поля. Но вы же с ИБ орете что вам надо Order — Item для одного отдела, TradingPeriod — Item для другого. Как же это вы свзянанные обьекты сможете представить для двух отделов. Как вы сможете собрать из этого ДТО для веб сервиса, если оно все в коде зареференшено.
Нивопрос.

var qForDep1 = _ordersRepository.With(o => o.Items);
var qForDep2 = from item in _itemsRepository
               group item by item.Year;

Модель данных одна, представлений — скольтко угодно.

MC>3) ты поубирал ИД поля. Это обозначает что у вас юзаеться ОРМ и тоже может юзаться лейзи лоад.
Естественно ОРМ, а LL вообще нету (EF) или отключаем (Linq2SQL)

MC>4) ты нарушил СРП в вашем понимании, обьекты теперь хранят не тока данные обьекта, но и ссылки на другие обьекты.
Ничего не нарушил. Объекты не меняются пока не изменилась модель данных.

G>>А вообще на лице денормализация. Надо бы еще объяснить зачем она нужна и почему бы не поддерживать целостность триггерами в БД, если денормализация нужна.
MC>Ты конкретней, ты где нашел денормализацию?
Хранение total в order.

MC>Ты про Тотал? Почитай про архитектуры финансовых систем. Там никогда агрегатные результаты не считаються динамически. Если один раз ордер продался по цене 20.00089 денег, то даже когда поменяеються требования к округлению он всеравно должно остаться 20.00089.
Там же вес, причем ту архитектура финансовых систем?

MC>Плюс номрализация Тотала не потдаеться юнит тестированию.
Это повод вносить денормализацию?

G>>Кстати, что здесь Order.Total? Почему мы total проверяем при сохранении, а не там где действительно надо (при отправке например)?

MC>Потому что это бизнес процес который считает тотал. И этот же бизнес процес должен сказать если там что-то не так.
Какой процесс? Там же создание заказа? Почему "создание заказа" считает Total, а не кто либо еще, кому оно надо?

MC>Отправка это вообще не контекстаная операция. Нафига мне валидировать тотал если он уже посчитан и дефакто валидный?
Потому что твой вариант таит больше проблем, чем ты можешь представить.
Нпапример пересчет тотала при добавлении\удалении\редактировании айтема.
Тебе понадобится поднять в память все айтемы для такой операции.
Очень дорогостоящее редактирование атема выйдет, если учесть что отправка ордера может и не произойти.


MC>В любом случае твой пример всеравно не читабельный. Попробуй его прочесть плаин текстом. Куча дублирования и мусора.
А ты не привел код AddItem.

Я кстати совершенно спокойно могу создать экстеншен метод AddItem и получить туже самую читаемоть что и у тебя.

Здравствуйте, meowth, Вы писали:

M>Здравствуйте, gandjustas и IB, Вы писали:

M>Нет, ребят, вы честно жжоте

M>Человек (Mike Chaliy) показывает вам на примере своего проекта, как оно работает -- что оно
Мы тут тоже все программированием занимаемся, если что

M>а)элегантно
Одинаково элегантно в любой модели. Anemic-Rich разницы не дает.

M>б)реально РАБОТАЕТ (это тоже важно)
Я свой кусок кода привел, который тоже реально работает.

M>б)легко сопровождаемо
На таком маленьком куске кода это незаметно будет. Anemic-Rich разницы не дает.

M>в)не содержит тех проблем, которые вы пытаетесь отыскать в решении.
На таком маленьком куске проблем тоже видно не будет. Хотя в том примере что Mike Chaliy привел проблемы таки есть, но они связаны с моделью опосредованно.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, meowth, Вы писали:

M>>Здравствуйте, gandjustas и IB, Вы писали:

M>>Нет, ребят, вы честно жжоте

M>>Человек (Mike Chaliy) показывает вам на примере своего проекта, как оно работает -- что оно
G>Мы тут тоже все программированием занимаемся, если что

M>>а)элегантно
G>Одинаково элегантно в любой модели. Anemic-Rich разницы не дает.

M>>б)реально РАБОТАЕТ (это тоже важно)
G>Я свой кусок кода привел, который тоже реально работает.

M>>б)легко сопровождаемо
G>На таком маленьком куске кода это незаметно будет. Anemic-Rich разницы не дает.

M>>в)не содержит тех проблем, которые вы пытаетесь отыскать в решении.
G>На таком маленьком куске проблем тоже видно не будет. Хотя в том примере что Mike Chaliy привел проблемы таки есть, но они связаны с моделью опосредованно.

Весь цимес в том, что он не доказывает и не собирается, что ваша модель -- плоха. Он говорит "ну, пользуйтесь anemic, раз вам в ней нормально. Но только имейте в виду, что Rich -- не такая ужасная, как вы думаете, а ее недостатки можно обойти, а не признавать неисправимыми"
А вы -- непременно пытаетесь это сделать по отношению к его модели: Rich model == evil под любым соусом.

Ладно, лучше я не буду спорить, потому что мне ближе его подход (особенно в плане чистоты бизнес-скриптов), и я буду необъективен. Уже, скорее всего

Здравствуйте, gandjustas, Вы писали:


MC>>1) ты отпарвил валидацию в конец, должно быть в начале, иначе возможны колизии, принцип фаил фаст знаеш? Обьяснить почему это проблема?
G>Ну попробуй объясни. У меня нету ни одной тяжелой операции, которая вызывается неявно. А наносекнуды, затраченные на создания объектов роли не играют.

http://en.wikipedia.org/wiki/Fail-fast
В общем случае обозначает что в начале метода должны быть гарантированы рабочие инварианты. Например number == null, а он используеться для генерации текстового представления Айтама. Упс. NullRefrenceException. Это тока иллюстрация. С точки зрения безопасности это хорошо описано в Writing Secure Code, Second Edition

MC>>2) ты поубирал ИД поля. Но вы же с ИБ орете что вам надо Order — Item для одного отдела, TradingPeriod — Item для другого. Как же это вы свзянанные обьекты сможете представить для двух отделов. Как вы сможете собрать из этого ДТО для веб сервиса, если оно все в коде зареференшено.
G>Нивопрос.
G>

G>var qForDep1 = _ordersRepository.With(o => o.Items);
G>var qForDep2 = from item in _itemsRepository
G>               group item by item.Year;
G>

G>Модель данных одна, представлений — скольтко угодно.
И что? Пусть будет без ИД, и хотя у тебя теперь не ПОКО, ну да ладно. Это все равно значительно не облечило чтение.
Ну и ты не боишся что всю БД выгрузиш в память .
А еще ты не боишся что каието рефернсы будут нулл?

MC>>4) ты нарушил СРП в вашем понимании, обьекты теперь хранят не тока данные обьекта, но и ссылки на другие обьекты.
G>Ничего не нарушил. Объекты не меняются пока не изменилась модель данных.
У вас меняющиеся понятие СРП, в прошлый раз было тока хранение данных.

MC>>Ты про Тотал? Почитай про архитектуры финансовых систем. Там никогда агрегатные результаты не считаються динамически. Если один раз ордер продался по цене 20.00089 денег, то даже когда поменяеються требования к округлению он всеравно должно остаться 20.00089.
G> Там же вес, причем ту архитектура финансовых систем?
Это стандарный паттерн для любых вычислений, архитектура финансовых систем это там где про это тебе удобней всего будет почитать.

MC>>Плюс номрализация Тотала не потдаеться юнит тестированию.
G>Это повод вносить денормализацию?
Да

G>>>Кстати, что здесь Order.Total? Почему мы total проверяем при сохранении, а не там где действительно надо (при отправке например)?

MC>>Потому что это бизнес процес который считает тотал. И этот же бизнес процес должен сказать если там что-то не так.
G>Какой процесс? Там же создание заказа? Почему "создание заказа" считает Total, а не кто либо еще, кому оно надо?
Потому что тотал должен быть сохранен единожды быв посчитан. Никто другой не должен самочинствовать и его считать. Кто-то другой может посчтиать какой-то свой тотал.

MC>>Отправка это вообще не контекстаная операция. Нафига мне валидировать тотал если он уже посчитан и дефакто валидный?
G>Потому что твой вариант таит больше проблем, чем ты можешь представить.
Конкретней, плз.
G>Нпапример пересчет тотала при добавлении\удалении\редактировании айтема.
Ессно у нас то рич модел, у нас не может получиться что тотал будет посчитан не правильно. И да пересчет тотала происходит при операциях с айтемами.

G>Тебе понадобится поднять в память все айтемы для такой операции.
G>Очень дорогостоящее редактирование атема выйдет, если учесть что отправка ордера может и не произойти.
Мы подымаем в память весь ордер со всеми айтемами. У нас это не вызвает проблем.

MC>>В любом случае твой пример всеравно не читабельный. Попробуй его прочесть плаин текстом. Куча дублирования и мусора.
G>А ты не привел код AddItem.
Зачем он тебе нужен если речь идет о читабельности этого метода. Я еще раз повторю, AddItem это черный ящик который гарантированно правильно добавит айтем и правильно изменит состояние ордера.

G>Я кстати совершенно спокойно могу создать экстеншен метод AddItem и получить туже самую читаемоть что и у тебя.
Добавив экстеншен метод у тебя получиться то о чем говорит ИБ. Ты не знаеш что делает AddItem. В рич моделе это решаеться скрытием состояния, рутагрегатами, боундариес, иммутабле валью обьектами и тому подобным. В анемик вы вообще никак не защищены от сайдеффектов. AddItem у вас может полезть в какуюто левую проперти, полезть в БД и тому подобное. Вобщемто экстеншен метод это будет самы главный антиагрумент.

Ты еше можеш и партиал использовать.

Собсно это был тока пример иллюстрирующий проблему, у AddItem может быть логика...

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:


MC>>>Мы этим гордимся, у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере. А все потому что DTO полностью развязаны. С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.
G>>
G>>Ведь гораздо легче вообще не иметь такой синхронизации.
MC>Гм, чем легче? Прототип набрасать да легче, а для потдерживаемого приложения вложения в эту синхронизацию не составляють и тысячных долей проекта....
Ты не понял, у меня готовые приложения без такого рода DTO работают. Вообще.
И поддерживаются отлично.

G>>>>Второе — достачно сложное создание произвольных выборок.
MC>>>Уже говорили, выборки это не респонсибилити доменной модели, это респонсибилити репортинга.
G>>
G>>Почему такая хорошая DDD заставляет выделять отдельное понятие репортинга? (на деле — любое отображение информации)
MC>Ым, потому что у нее респонсибилити другая... У репортинга своя, у модели другая...
Странно, я anemic использую, ни разу не доходило до создания отдельной инфраструктуры репортинга (отображения).
Что тогда DDDшными методами делается?

G>>Суть не в DTO, а в способах его получения.
MC>И чем они отличаються? Если ты думаеш что мы пользуемся чем то секретным ты ошибаешся, все на виду...
Код в студию.

MC>>>Решение и для рич моделей и для анмемичных идентичное.
G>>Ну покажи полное решение для такого случая в rich, учитывая что надо получать далеко не все все товары, там есть пейджинг, видимость, выборка по категории итп. Для каждого товара существует куча картинок и надо получить первую.


MC>

MC> (from p in Query() // Query возвращет IQueryable<Product>
MC>        where p.Category.Contains("sdfsdf")
MC>        select new ProductListItem(){
MC>          Name = p.Name; 
MC>          ImageUrl = p.Images.First().Url
MC>        }).Take(10).ToList();
MC>

Ух ты, прям как у меня.
Тогда зачем вообще DDD? Aggregation roots всякие.
Где же Ubiquitous Language и читаемый Domain Expretом код?
Кстати, а кто вызывает показанный выше код?

MC>Чето типа того, писал прямо тут, могут быть ошибки.
MC>В реальной реализации пейджинг, сортинг, фильтры находятсья в инфраструктуре.
В какой инфраструктуре. Давай полный пример.
На входе есть products:IQueryable<Product>, который возвращает все записи. Показать надо первые 10 видимых, из категории X.
Какие будут классы, как распределена логика?

Здравствуйте, meowth, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, meowth, Вы писали:

M>>>Здравствуйте, gandjustas и IB, Вы писали:

M>>>Нет, ребят, вы честно жжоте

M>>>Человек (Mike Chaliy) показывает вам на примере своего проекта, как оно работает -- что оно
G>>Мы тут тоже все программированием занимаемся, если что

M>>>а)элегантно
G>>Одинаково элегантно в любой модели. Anemic-Rich разницы не дает.

M>>>б)реально РАБОТАЕТ (это тоже важно)
G>>Я свой кусок кода привел, который тоже реально работает.

M>>>б)легко сопровождаемо
G>>На таком маленьком куске кода это незаметно будет. Anemic-Rich разницы не дает.

M>>>в)не содержит тех проблем, которые вы пытаетесь отыскать в решении.
G>>На таком маленьком куске проблем тоже видно не будет. Хотя в том примере что Mike Chaliy привел проблемы таки есть, но они связаны с моделью опосредованно.

M>Весь цимес в том, что он не доказывает и не собирается, что ваша модель -- плоха. Он говорит "ну, пользуйтесь anemic, раз вам в ней нормально. Но только имейте в виду, что Rich -- не такая ужасная, как вы думаете, а ее недостатки можно обойти, а не признавать неисправимыми"
Тут есть некоторое отношение порядка, выражение для которого еще не придумано (и вряд ли будет придумиано когда-нибудь). Назовем его "лучше".
Так вот мы пытаемся показать что anemic лучше rich, а Mike Chaliy говорит что rich лучше anemic, причем неважно каким способом указывая недостатки одно из подходов или достоинства другого.

Здравствуйте, gandjustas, Вы писали:

MC>>

MC>> (from p in Query() // Query возвращет IQueryable<Product>
MC>>        where p.Category.Contains("sdfsdf")
MC>>        select new ProductListItem(){
MC>>          Name = p.Name; 
MC>>          ImageUrl = p.Images.First().Url
MC>>        }).Take(10).ToList();
MC>>

G>На входе есть products:IQueryable<Product>, который возвращает все записи. Показать надо первые 10 видимых, из категории X.
G>Какие будут классы, как распределена логика?

Сорри, что лезу, но имхо все написано же:
p.Category.Contains("sdfsdf")... // из категории X
.. .Take(10) ... // первые 10

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Хотел бы подвергнуть сомнению все эти пункты:
ЛИ>1) Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
Тут я бы проитерполировал сложность сопровождения в зависимости от количества сущностей. При большом количестве, RDM должен быть эффективней. Но RDM также приводит к более высоким требованиям по качеству архитектуры и качеству дизайна.

ЛИ>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
В паттернах Фаулера есть ключевое слово Enterprise о котором часто забывают. А это практически всегда означает, что клиенты как минимум хотят с кем-то, зачем-то интегрироваться. Поэтому переносимость нужна. А ежели объекты отчуждаемы, то это ващщее... Кроме того, даже на уровне потребления нельзя использовать голые классы. Иначе мы нарушаем изоляцию через фасад.
Насчет инструментов — я не возражал.

ЛИ>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
В том то и дело, что ADM все это нормально переваривает без костылей.

ЛИ>4) Постоянная валидность бизнес-объектов и RDM -- совершенно не связанные между собой аспекты, в случае ADM точно так же можно наложить ограничение постоянной валидности.
В ADM это как раз сделать очень сложно.

ЛИ>К тому же современные средства валидации бизнес-объектов поддерживают несколько степеней валидности, в зависимости от контекста.
Без возражений. Только вопрос что имелось ввиду под средствами?

ЛИ>То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM
Немножко добавлю. Я — разработчик NET. В случае реализации ADM, я собираю приложения не пользуясь излишним инструментарием(ну ессно это не касается отчетов, OLAP и другой специализации). Это позволяет уменьшать сложность вхождения в проект, углубляет понимание самих процессов происходящих в решении. Я могу на коленке, собрать приложение любой степени сложности. И второе, что хотелось бы повторить. Я хочу не отвлекаться на правильность дизайна OOP. В реальности, реализация правильного дизайна OOP — весьма сложная штукенция. Можно заделать грабли.

ЛИ>P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно:
ЛИ>http://javatoday.ru/2009/03/rich-domain-model/
Что-то уж очень страшное. Или я ваще ничего не понял, или одно из двух. У постановки может быть большое кол-во графов. Ну например, есть иерархия подчинения, типа отдел с директором, подчиненные подразделения и т.д. А есть проектные группы, которым эта иерархия ваще по барабану, так как там 3 чела с одного подразделения, 2 чела с другого. И у этих двух иерархий, независимые связи и некоторая ортогональная логика. Зачем мешать все в одном объекте? Не проще ли выделить некоторую логику в раздельные сервисы? Band of Four здря книжки писали?

Здравствуйте, gandjustas, Вы писали:


M>>Весь цимес в том, что он не доказывает и не собирается, что ваша модель -- плоха. Он говорит "ну, пользуйтесь anemic, раз вам в ней нормально. Но только имейте в виду, что Rich -- не такая ужасная, как вы думаете, а ее недостатки можно обойти, а не признавать неисправимыми"
G>Тут есть некоторое отношение порядка, выражение для которого еще не придумано (и вряд ли будет придумиано когда-нибудь). Назовем его "лучше".
G>Так вот мы пытаемся показать что anemic лучше rich, а Mike Chaliy говорит что rich лучше anemic, причем неважно каким способом указывая недостатки одно из подходов или достоинства другого.

Покажите, где он говорит, что "лучше". Он говорит -- не хуже, потому что описанные вами ужос-нахи, которые неотвратимо настигнут всякого, осмелившегося поюзать rich, зачастую надуманны и оторваны от практики, а вы с эти спорите
причем где _вы_ говорите, что anemic лучше, я вижу -- например, в строчке выше; вы и не скрываете

Здравствуйте, meowth, Вы писали:

M>А вы -- непременно пытаетесь это сделать по отношению к его модели: Rich model == evil под любым соусом.
Гы-гы. Собственно поэтому я и открыл этот флейм.

Здравствуйте, GlebZ, Вы писали:

GZ>Ну наконец — то.
То есть, метрика таки есть. уже хорошо.

GZ>Ну и что тут обсуждать?
Сам не понимаю, я тебе про одно, а ты про другое.

GZ>Это аггрегируемая информация.
Да ну нет же.

GZ> Ибо на физическом уровне, доступ управляется набором идентификаторов связанных с объектом.
Так родительский идентификатор в объекте и так есть, тогда вообще ничего дополнительно делать не надо.

GZ> По каждому чиху просчитывать информацию? Гениальное решение.
По каждому чиху, вообще ничего делать не надо.

GZ>Ты читаешь что я пишу?
Похоже ты не читаешь, что я пишу.

GZ>Зачем????
За тем, что это важно, код понятнее и очевиднее.

GZ>Не проще ли на самом солнце кликнуть и не разбираться с проблемами бытия, орбит, и магнитных бурь.
Не проще, потому что когда понадобится щелкнуть этими тумблерами в обратном порядке, с одним ты ничего не сделаешь.

IB>>Причем забыть и не передать, я не могу — компилятор поправит.
GZ>Не поправит. У тебя интерфейс не изменяется, а только дополняется.
Ты серьезно считаешь, что если я изменю сигнатуру метода с CanEdit(id), на CanEdit(id, id), мне компилятор ничего не скажет?!!

GZ>А вот зачем? Весь смысл Rich, это то что ты абстрагируешься от БД.
Да затем, что не во всех сценариях нужно абстрагироваться — дырявая абстракция получается.

GZ>Нет. В Rich — все места связаны с методом объекта.
В Anemic тоже, только другого объекта. Вопрос не как, а по какому принципу.
В Rich — object cohesion, в Anemic — functional cohesion, и последнее — существенно лучше, с точки зрения поддрежки и изменения кода.

GZ> Объект и контекст пользователя, все что нужно для пользы дела. Все остальные проблемы, как зависимость от типа, можно решить в одном конкретном месте.
Нельзя, если типов больше одного, а вот в anemic как раз можно, вне зависимости от их количества.

GZ>Звиняюсь, coupling.
coupling как раз уменьшается.

GZ>То, что можно изменить полиморфно поведение в одном месте существенно увеличивает поддержку?
Во-первых не полиморфно, а во-вторых, существенно ухудшает, как только появляется дополнительный сценарий.

GZ>В Rich — строго наоборот. Объект решает как ему проверяться. Это большая разница.
Конечно, это один из основных косяков Rich, так как проверка зависит от контекста, значит объект должен знать обо всех контекстах.

GZ>С чего ты решил?
Со здравого смысла.

Здравствуйте, Mike Chaliy, Вы писали:

MC>Тебя интересует как работает Add это к ОРМ тулу твоего выбора.
Меня интересует, как это работает у тебя.

MC>Тебя интересует как работает Mapэто к мапперу твоего выбора.
И это тоже.

MC>И что там не к месту?
Определение твое не к месту.

MC> Именно реализация этого языка это и есть респонсибилити.
Тогда ты вообще не о тех объектах.

MC>Нарпимер для респонсибилити обьекта ордер это реализация языка по работе с оредорм.
Так данные-то где?

Здравствуйте, Mike Chaliy, Вы писали:

MC>Нам надо менять тока в том месте где надо.
Ну вот, а мы как раз про сценарий, когда везде надо. Как самый геморройный и самый часто встречающийся.

MC>Ну и кто дурак? У нас такого не быват. У нас публичный АПИ тестируеться.
А, то есть, твоя претензия к стройной модели сводится к тому, что там ничего не тестируется?
Вообщем, кончай заливать, что у вас все зашибись как изолировано.

MC>Для меня это вообще не новость, у нас репортинг это инфраструктура к которой модель вообще не имеет отношения.
А к чему же у вас тогда модель имеет отношение?

MC>Если тебе хочеться сказать что типа ваша модель покрывает 5% кода приложения, а вот наша анемичная 95%(мне кажеться 40%), я с тобой вполне согласен. Для нас это не являеться камнем претконовения. Все ДТО у нас анемичны по определению.
Отлично, так зачем вам тогда не DTO? Чтобы оставшиеся 5% выглядели красиво и правильно, по книжке?
Какую проблемы вы решаете, городя true domain model — чтобы ORM работал?

MC>LINQ никто не отменял, с чего ты взял что мы не используем LINQ? У нас куча траверсинга на LINQ, репорты тож на LINQ...
Ну правильно, у вас же там плоский DTO.

Здравствуйте, meowth, Вы писали:

M>Человек (Mike Chaliy) показывает вам на примере своего проекта, как оно работает
В том, то и дело, что не показывает.

M>-- что оно а)элегантно б)реально РАБОТАЕТ (это тоже важно) б)легко сопровождаемо в)не содержит тех проблем, которые вы пытаетесь отыскать в решении.
Оно нифига не "элегантно", как выясняется, работать может вообще все, как я уже говорил, а про проблемы отдельный разговор. Тут вот походу выясняется, что свою красивую модель он вообще не использует, а использует повсюду DTO, а модель как раз для красоты и элегантности — понятно что проблем нет.

M> Но при этом почему-то сами ставите ему вопрос, сами отвечаете, и в своем ответе находите недочеты, которые приписываете решению.
Ну так он-то не отвечает, вот и приходится гадать.. =)

Здравствуйте, Mike Chaliy, Вы писали:

MC>И что там не очевидного? И что ты не можеш предсказать?
Совершенно непонятно, что валидируется, как и с привлечением каких контекстов, непонятно, что из себя представляет продукт и откуда берется, ect...


MC>Так еще более читабельней... И респонсибилити ясна.
MC>public CreateOrder(number){
MC>}
Ну вот примерно так твой код и выглядит...

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Здравствуйте, gandjustas, Вы писали:


MC>>>>Мы этим гордимся, у нас не бывает ситуаций когда поменял чето в доменной моделе а отвалиось гдето на ремо сервере. А все потому что DTO полностью развязаны. С свременными ИДЕ и тулингом потдерживать такую синхронизацию очень дешево.
G>>>
G>>>Ведь гораздо легче вообще не иметь такой синхронизации.
MC>>Гм, чем легче? Прототип набрасать да легче, а для потдерживаемого приложения вложения в эту синхронизацию не составляють и тысячных долей проекта....
G>Ты не понял, у меня готовые приложения без такого рода DTO работают. Вообще.
G>И поддерживаются отлично.

Ну у меня тож есть приложения в которых уи на веб формах, логика-доступ к данным в одном слое, сотни класов менеджеров. И это все работает и потдерижвается. И что?

Ты же не можеш сравнить скорости добовления фитчеров. То что ты называеш рич моделью таковой не являеться. Соотвевенно у тебя просто нет опыта сравнить эти два подхода. Тебе с твоим подходом комфортней ок. У нас в команде рич модели это дефолтная архитектура. В тоже время рич модели не отменяют анемичных сущьностей. Всякие справочники, это просто инфа. Там нема логики. Для этого есть shared kernerl of value objects .

G>Странно, я anemic использую, ни разу не доходило до создания отдельной инфраструктуры репортинга (отображения).
G>Что тогда DDDшными методами делается?
Тока бизнес модели. Все построенно вокруг бизнес моделей. Если доменная область не позволяет построить рич модель, то естесвенный фалбек в анемичные модели. Соотвевенно иммутабилити обьектов, и соотвевенно возможность периспользовать сущьности в других слоях.
Рич модель идеальна когда стоимость реализации бизнес модели это самая большая часть бюджета. В ентрерпрайз приложениях это очень часто. Хотя уровень писателей ентерпрайз приложений обычно очень низок. А это приводит что люди думают в терминах хранилища данных. Что естевенно приводит к анемичным моделям, так как у таблиц нема поведения.

G>>>Суть не в DTO, а в способах его получения.
MC>>И чем они отличаються? Если ты думаеш что мы пользуемся чем то секретным ты ошибаешся, все на виду...
G>Код в студию.

 (from p in Query() // Query возвращет IQueryable<Product>
        where p.Category.Contains("sdfsdf")
        select new ProductListItem(){
          Name = p.Name; 
          ImageUrl = p.Images.First().Url
        }).Take(10).ToList();

MC>>>>Решение и для рич моделей и для анмемичных идентичное.
G>>>Ну покажи полное решение для такого случая в rich, учитывая что надо получать далеко не все все товары, там есть пейджинг, видимость, выборка по категории итп. Для каждого товара существует куча картинок и надо получить первую.

MC>>

MC>> (from p in Query() // Query возвращет IQueryable<Product>
MC>>        where p.Category.Contains("sdfsdf")
MC>>        select new ProductListItem(){
MC>>          Name = p.Name; 
MC>>          ImageUrl = p.Images.First().Url
MC>>        }).Take(10).ToList();
MC>>

G>Ух ты, прям как у меня.
G>Тогда зачем вообще DDD? Aggregation roots всякие.
Это репорт это не логика. DDD и всякие Aggregation roots нужны для постоения модели.

G>Где же Ubiquitous Language и читаемый Domain Expretом код?
В доменной модели.

G>Кстати, а кто вызывает показанный выше код?
Именно этот УИ. Метод MVC контроллера.

var query = new ListAllProductsQuery{};
var page = Get<IReportingService>().QueryPage(query);
return page.Results.Map(p => ProductListItemMapInstance.Map(p))

MC>>Чето типа того, писал прямо тут, могут быть ошибки.
MC>>В реальной реализации пейджинг, сортинг, фильтры находятсья в инфраструктуре.
G>В какой инфраструктуре. Давай полный пример.
G>На входе есть products:IQueryable<Product>, который возвращает все записи. Показать надо первые 10 видимых, из категории X.
G>Какие будут классы, как распределена логика?
Логики нет. Она тока в модели. Это по этому и денормализщация с тоталом.
Так настраиваеть query оьект. Это старая версия, щас более унифицированная версия...
var query = new ListAllProductsQuery
{
MaxResults = limit ?? 256
StartFrom = start,
SortFieldExpression = sort, // TODO Security hole, we should restrict select strings...
Direction = String.Equals(dir, "asc", StringComparison.OrdinalIgnoreCase)
? OrderDirection.Asc : OrderDirection.Desc
};

В ListAllProductsQuery доступна IQueryable НХибирнейта, весь пейджинг и фильтры там делаються там.
тож нужен пример?
IQueryable.Where().Take() и чето-там.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Mike Chaliy, Вы писали:

MC>>Тебя интересует как работает Add это к ОРМ тулу твоего выбора.
IB>Меня интересует, как это работает у тебя.
MC>>Тебя интересует как работает Mapэто к мапперу твоего выбора.
IB>И это тоже.
Сорри, я наверное туплю. Но я просто вызываю эти методы. Замени слова ЭТО на что-то конкретное.

MC>>И что там не к месту?
IB>Определение твое не к месту.
Ты его просто не понимаеш. Если бы понял, все было бы к месту. но судя по всему я не смогу обьяснить.

MC>> Именно реализация этого языка это и есть респонсибилити.
IB>Тогда ты вообще не о тех объектах.
Или ты не о тех. А ты о каких?

MC>>Нарпимер для респонсибилити обьекта ордер это реализация языка по работе с оредорм.
IB>Так данные-то где?
Поля обьекта. В его внутренней реализации. Хотя я не вижу особой разницы, может быть бег какой-то. Ты к чемуто клониш? Уж не к своему пониманию СРП, про то что хранение данных это уже достаточная респонсибилити?

Здравствуйте, Mike Chaliy, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:


MC>>>1) ты отпарвил валидацию в конец, должно быть в начале, иначе возможны колизии, принцип фаил фаст знаеш? Обьяснить почему это проблема?
G>>Ну попробуй объясни. У меня нету ни одной тяжелой операции, которая вызывается неявно. А наносекнуды, затраченные на создания объектов роли не играют.

MC>http://en.wikipedia.org/wiki/Fail-fast
MC>В общем случае обозначает что в начале метода должны быть гарантированы рабочие инварианты. Например number == null, а он используеться для генерации текстового представления Айтама. Упс. NullRefrenceException. Это тока иллюстрация. С точки зрения безопасности это хорошо описано в Writing Secure Code, Second Edition
К обсуждаемой теме отношения не имеет.
В реальном случае я бы Code Contracts вопользовался.

MC>И что? Пусть будет без ИД, и хотя у тебя теперь не ПОКО, ну да ладно. Это все равно значительно не облечило чтение.
К чему это?

MC>Ну и ты не боишся что всю БД выгрузиш в память .
нет, я LL принципиально не использую.

MC>А еще ты не боишся что каието рефернсы будут нулл?
Если они могут быть нулл, тогда будут проверки, если нет — то нет.

MC>>>4) ты нарушил СРП в вашем понимании, обьекты теперь хранят не тока данные обьекта, но и ссылки на другие обьекты.
G>>Ничего не нарушил. Объекты не меняются пока не изменилась модель данных.
MC>У вас меняющиеся понятие СРП, в прошлый раз было тока хранение данных.
А это и есть. Ведь есть productId — данные, а ссылка product только слегка упрощает работу.
Определение SRP одно, советую внимательно его изучить. Он является основопологающим принципом хоршего дизайна.

MC>>>Ты про Тотал? Почитай про архитектуры финансовых систем. Там никогда агрегатные результаты не считаються динамически. Если один раз ордер продался по цене 20.00089 денег, то даже когда поменяеються требования к округлению он всеравно должно остаться 20.00089.
G>> Там же вес, причем ту архитектура финансовых систем?
MC>Это стандарный паттерн для любых вычислений, архитектура финансовых систем это там где про это тебе удобней всего будет почитать.
Это ты сам придумал. Денормализацию в твоем слуцчае это никак не оправдывает.

MC>>>Плюс номрализация Тотала не потдаеться юнит тестированию.
G>>Это повод вносить денормализацию?
MC>Да
Надесь ты уже сосознал сколько проблем ты себе таким создал.
Можно пойти дальше, например есть у нас представление Order — Items, показанное выше и SalePeriod — Items, ты предложишь кешировать сумму по периоду тоже (учитывая доводы что ты приводил выше)? А где её кешировать?
А как после кучи таких кешировангий будет выглядеть код CUD для Item?

G>>>>Кстати, что здесь Order.Total? Почему мы total проверяем при сохранении, а не там где действительно надо (при отправке например)?

MC>>>Потому что это бизнес процес который считает тотал. И этот же бизнес процес должен сказать если там что-то не так.
G>>Какой процесс? Там же создание заказа? Почему "создание заказа" считает Total, а не кто либо еще, кому оно надо?
MC>Потому что тотал должен быть сохранен единожды быв посчитан. Никто другой не должен самочинствовать и его считать. Кто-то другой может посчтиать какой-то свой тотал.

Ты расскажи зачем этот тотал нужен. Пока он никому не нужен его и считать не надо.
А то получается что ты придумал фигню, а теперь придумываешь оправдания.

Хочешь честно — давай исходные требования и разберем как их надо реализовывать.

MC>>>Отправка это вообще не контекстаная операция. Нафига мне валидировать тотал если он уже посчитан и дефакто валидный?
G>>Потому что твой вариант таит больше проблем, чем ты можешь представить.
MC>Конкретней, плз.
G>>Нпапример пересчет тотала при добавлении\удалении\редактировании айтема.
MC>Ессно у нас то рич модел, у нас не может получиться что тотал будет посчитан не правильно. И да пересчет тотала происходит при операциях с айтемами.
Уже начинаю плакать от смеха.
Таким образом мы получили пеессимизацию на ровном месте.
Кстати смотри выше SalePeriod — Items, как будешь выкручиваться?

G>>Тебе понадобится поднять в память все айтемы для такой операции.
G>>Очень дорогостоящее редактирование атема выйдет, если учесть что отправка ордера может и не произойти.
MC>Мы подымаем в память весь ордер со всеми айтемами. У нас это не вызвает проблем.
Браво, для редактирования одного айтема поднять в память полбазы — номальное явление для rich, ты это только что доказал.

MC>>>В любом случае твой пример всеравно не читабельный. Попробуй его прочесть плаин текстом. Куча дублирования и мусора.
G>>А ты не привел код AddItem.
MC>Зачем он тебе нужен если речь идет о читабельности этого метода. Я еще раз повторю, AddItem это черный ящик который гарантированно правильно добавит айтем и правильно изменит состояние ордера.
Ну не увиливай, приведи код. А то два куска неэвивалентны.

G>>Я кстати совершенно спокойно могу создать экстеншен метод AddItem и получить туже самую читаемоть что и у тебя.
MC>Добавив экстеншен метод у тебя получиться то о чем говорит ИБ.
о чем он говорит?

MC>Ты не знаеш что делает AddItem.
И ты не знаешь что делает AddItem в твоем случае. Это надо проверять тестами.

MC>В рич моделе это решаеться скрытием состояния, рутагрегатами, боундариес, иммутабле валью обьектами и тому подобным.
От кучи страшных слов гарантий не появится.

MC>В анемик вы вообще никак не защищены от сайдеффектов.
В rich вообще говоря тоже. Поэтому пишутся тесты.
Есдинственное отличие, что в anemic эти эффекты получить проще, но это проверяется тестами и программисты не заинектерованы писать неправильный код.

MC>AddItem у вас может полезть в какуюто левую проперти, полезть в БД и тому подобное. Вобщемто экстеншен метод это будет самы главный антиагрумент.
Твой AddItem может сделать тоже самое. Тебе все равно нужен способ доказать что он этого не делает.
Кстати в случае экстеншена у него меньше возможностей полезть во внутренее состояние объекта, поэтому экстеншены предпочтительнее. В Design Guidelines так и написано.

MC>Ты еше можеш и партиал использовать.
Партиал — обратный случай. Слишком много он может сделать с объектом.

MC>Собсно это был тока пример иллюстрирующий проблему, у AddItem может быть логика...
Тогда можно стразу идти стреляться. Потому что по коду программы станет невозможно определить что она делает.
В случае с extension кстати особо навороченную логик не засунешь. Экстеншену не откуда брать ссылку на SqlConnection например.