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

T>Нет dataobjects в domain model, потому и такого явления как "зашивание логики в data objects", а следовательно нет и "расползанием изменений". domain model рулит!
domain model по фаулеру и есть dataobjects+"какое-то мифическое поведение". А расползание вы получите при первом же изменении бизнес требований.
например рассмотрим ввод данных. Раз у вас "сущности" не байндятся на контролы, то валидацию в процессе ввода вы получить не сможете. Поэтому вам придется продублировать логику валидации в UI, чтобы сделать хороший фидбэк.
Если у вас меняется логика валидации, то вам уже надо менять в двух местах.

Можно такой же пример с разграничением доступа рассмотреть. Если логика проверки прав вшита внутрь "сущности", то вам придется её продублировать в UI чтобы скрыть\задизейблить ненужные контролы.

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

S>Здравствуйте, Tissot, Вы писали:
T>>Зачем это ID в кастомере? Просто передавай в метод обработки список кастомеров.
S>Откуда возьмется "список"?

Оттуда же откуда взялся у тебя свзязаный список.

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

Ну не надо Фаулера уж совсем за идиота считать. Понятно же, что анализ/моделирование присутствует всегда.

T>>Нет, не попадает. Если в предметной области этого не было, то зачем откуда оно в сущностях? Они же (сущности) — результат анализа предметной области.
S>Как артефакт анализа. Простейшая штука — ID. В предметной области никаких суррогатных ключей нету. В данных почему-то появляются.

Анализ всегда есть. Он предполагается "по умолчанию"

S>В предметной области нет никаких понятий типа "доступа", они появляются только после моделирования. Этакие "сущности второго порядка".

Почему нет? Ест такие понятия. Только формулируются они не как "существительные", а как некоторые правила, ограничения.

S>В развитом приложении, к примеру, правила валидации сами становятся "сущностями", хотя никакому объекту в предметной области они не соответствуют.

Для них нет "физического" представления в предметной области, но есть концептуальное.

S>В итоге, применение ООП для моделирования "реального мира" в большинстве случаев совершенно бесполезно.

Отнюдь.

S>Вообще, напомню, что ООП появилось как попытка разработать удачную абстракцию для оконно-ориентированного GUI. Именно поэтому в ранних книгах по ООП так много примеров на тему pWindow->draw() или pFigure->draw().
S>Прошли годы, и оказалось, что даже для этих задач ООП в таком виде малопригодно.
S>Что окна удобнее собирать из готовых примитивов как агрегаты, а не наследовать друг от друга.
S>Что и геометрические фигуры не надо наследовать друг от друга, а достаточно иметь ровно один класс VectorPath, который рисуется ровно одним образом, а бытность его квадратом или треугольником — всего лишь предикат, а не имманентное свойство.

Ты очень правильно выделил "в таком". Но из того, что "в таком виде малопригодно" не следует, что ООП само по себе непригодно.

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

T>>Ответственности тоже можно порезать по-разному. Можно — по модифицирующим сущностям (CustomerManager, OrderManager), можно и по бизнес — сценариям (ReservationService).
S>Первый способ — неправильный; второй — правильный.

Зачем ты тогда его ввел?

T>>Нет, я боролся за то, чтобы те сделать контракт сущности таковым, чтобы нельзя было нарушить инварианты. Если метод работы с сущностью не нарушает инвариантов, то его можно поместить и вовне класса, например в виде extension-метода, если мы используем C#. Если область действия метода шире чем данный экземпляр класса, то ему не место в классе, нужно завести отельный сервис, в котором и реализовывать необходимый функционал.
S>Всё правильно. Повторюсь: при анализе предметной области тех инвариантов, о которых ты говоришь, возникает пренебрежимо мало.
S>Даже самые очевидные штуки, типа "остатки на складе не могут быть меньше нуля" в реальной жизни оказываются неверными (например, из-за того, что оприходование товара выполняется с опозданием).

Еще раз. Это другой вопрос, это проблема анализа, не программирования.

T>>Дык, ReservationService и не является частью domain model. Это бизнес-операция.
S>Ну вот очень странно получается — важное поведение не попадает в модель.

Неудачно выразился. Резервирование не является опреацией entity, а является отдельным сервисом.

S>Это получается какая-то плохая модель, некачественная. Непонятно, почему одно поведение входит в модель, а другое — нет.

Очень все понятно. И критерий отнесения к entity тоже был сформулирован.

S>В анемичной модели всё просто: "сущности" моделируют только статическую часть предметной области, у них нет никакого поведения. А всё поведение сосредоточено во всяких ...Manager, ...Service, ...Strategy, ...Policy.

Ну так и в domain model не особо сложнее: entity, service, repository, ...

T>>Ну так как его использовать, если функциональность изменения остатков на складе уже переползла из соответствующего менеджера в ReservationService?
S>Очень просто — в данном сценарии ReservationService и стал "соответствующим менеджером"

То есть меняем мы не только в соответствующем менеджере, но и в сервисах?

T>>Из того, что "Договор заключается с каждым отдельным заказчиком" не следует, что договоры с заказчиками не имеют ничего общего. Первое что приходит в голову — это название заказчика и SLA. Кроме того, каждый заказчик регистрируется в бухгалтерской системе, в которой он получает свой номер. Этот номер — второй претендент на проверку.
S>На проверку чего?

На проверку того, что этот номер указан у кастомера

S>Намекну: бухгалтерская система может быть завтра заменена, без изменения бизнеса.

Сильно ошибаешься. Это такая замена, которая меняет многие бизнес-процессы в организации, без изменения бизнеса не получится.

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

T>>Нет dataobjects в domain model, потому и такого явления как "зашивание логики в data objects", а следовательно нет и "расползанием изменений". domain model рулит!
S>Ну щас прямо. То, что было бы в анемичной модели банальной структурой "кастомер", то бишь дата обжектом, в твоей "domain model" обрастает какими-то методами, валидацией там, и так далее. В итоге изменения таки расползаются.

Так изменения и у тебя расползаются. Инварианты же тебе все равно придется проверять во всех своих сервисах/менеджерах. Где преимущество?

T>>Правильно, не был проведен анализ.
S>Почему это? Представь себе реальную жизнь — бизнес эволюционирует, требования, которых не было в Release 1, появляются в Release 2.
S>Как бы ты ни пыхтел в Release 1, всех требований ты предсказать не можешь

Конечно не можешь, но если в результате анализа в первом релизе решили что болжна быть валидация, то она есть по-любому, вне зависимости от того, используем ли мы анимичную модель или rich.

T>>И какой вывод? Отказаться от валидации совсем? Дык это не решение, т.к. если на этапе анализа было решено, что валидация нужна, то и моем и в твоем случае ее делать придется.
S>Только в моём случае не придется менять класс Customer при изменении требований к валидации.
Тебя смущает,. что файл, в котором лежит объявление атрибутов сущности, меняется или что-то еще?
Если первое, то это легко решить при помощи тех же partial-классов (C#).

Здравствуйте, Tissot, Вы писали:
T>Оттуда же откуда взялся у тебя свзязаный список.
Еще раз объясняю: чтобы упорядочить список кастомеров "в реале", не нужно ничего. Можно просто написать их на бумажке в нужном порядке.
В программировании нет концепции "пространственного расположения", поэтому нужно искусственно ввести в "описание кастомера" какие-то дополнительные данные.
Либо номер его позиции в списке, либо ссылку на следующего в списке.
Ни то ни другое не имеет отношения к предметной области. Это — артефакты моделирования. Точно так же, как и табличка для связи "многие-ко-многим" не соответствует никакому классу объектов предметной области.

T>Ну не надо Фаулера уж совсем за идиота считать. Понятно же, что анализ/моделирование присутствует всегда.
Пока что непонятно. Ты очень ловко манипулируешь понятием "domain model". В итоге, она моделирует всё, что угодно. Как у Лема про сепульки.
Так всё-таки, что именно моделирует domain model? К чему она должна быть близка?
Мне как-то не хочется пользоваться термином, определенным через самого себя.

T>Ест такие понятия. Только формулируются они не как "существительные", а как некоторые правила, ограничения.
И какие же правила в предметной области соответствуют DACL?

T>Для них нет "физического" представления в предметной области, но есть концептуальное.
Что такое "концептуальное представление"?

T>Ты очень правильно выделил "в таком". Но из того, что "в таком виде малопригодно" не следует, что ООП само по себе непригодно.
Никто и не протестует против ООП вообще. Просто в бизнесе полиморфизм оказывается применим не к данным, а к сервисам. Применять всю мощь ООП к данным — примерно то же самое, что одушевлять бухгалтерские проводки

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

G>domain model по фаулеру и есть dataobjects+"какое-то мифическое поведение".

Я вчера не поленился и бегло посмотрел Фаулера. Он ссылается на книжку Эванса, которая на момент публикации PoEA не была доступна. Сейчас он уже несколько лет как ледит в магазинах. Там DDD расписан более подробно.

G>А расползание вы получите при первом же изменении бизнес требований.
G>например рассмотрим ввод данных. Раз у вас "сущности" не байндятся на контролы, то валидацию в процессе ввода вы получить не сможете. Поэтому вам придется продублировать логику валидации в UI, чтобы сделать хороший фидбэк.
G>Если у вас меняется логика валидации, то вам уже надо менять в двух местах.

Есть и другой вариант — логика валидации лежит во внешнем классе, а при изменении сущности этот внешний класс пользуется сущностью. И получили руюз.

G>Можно такой же пример с разграничением доступа рассмотреть. Если логика проверки прав вшита внутрь "сущности", то вам придется её продублировать в UI чтобы скрыть\задизейблить ненужные контролы.

То же самое может быть сделано и для разграничения доступа.

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

T>Так изменения и у тебя расползаются. Инварианты же тебе все равно придется проверять во всех своих сервисах/менеджерах. Где преимущество?
Э нет. Тут фишка в том, что за формулировку "инвариантов" отвечает один класс, а за проверку — разные.
К примеру, UI запрашивает у бизнеслогики набор правил валидации, благодаря чему пользователь получает "упс" не дожидаясь коммита.
При этом само по себе правило записано ровно один раз.

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

T>Тебя смущает,. что файл, в котором лежит объявление атрибутов сущности, меняется или что-то еще?
T>Если первое, то это легко решить при помощи тех же partial-классов (C#).
Не вижу ничего легкого.

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

T>Ну так и в domain model не особо сложнее: entity, service, repository, ...
Непонятно, по каким критериям распределяется логика между entity, service и repository.

T>То есть меняем мы не только в соответствующем менеджере, но и в сервисах?
Что именно меняем?

T>На проверку того, что этот номер указан у кастомера
Ок, то есть мы с трудом придумали неубедительный пример с not null инвариантом. Как и следовало ожидать,
а) этот пример достаточно сомнительный. В том смысле, что дальнейший анализ запросто может привести к тому, что в реальных сценариях нам нужно разрешать работу с кастомером еще до того, как его "номер" будет доступен
б) это настолько мягкий инвариант, что большую роль ему придавать я бы не стал. Ну то есть он же ничего не говорит ни о структуре этого номера, ни о том, что он соответствует какой-то реальной записи в бухгалтерской программе, ни, тем более, о том, что по этому номеру там заведен именно этот кастомер, а не просто сделана ошибка.

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

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

T>>Оттуда же откуда взялся у тебя свзязаный список.
S>Еще раз объясняю: чтобы упорядочить список кастомеров "в реале", не нужно ничего. Можно просто написать их на бумажке в нужном порядке.
S>В программировании нет концепции "пространственного расположения", поэтому нужно искусственно ввести в "описание кастомера" какие-то дополнительные данные.
S>Либо номер его позиции в списке, либо ссылку на следующего в списке.
S>Ни то ни другое не имеет отношения к предметной области. Это — артефакты моделирования. Точно так же, как и табличка для связи "многие-ко-многим" не соответствует никакому классу объектов предметной области.

Ты узко трактуешь понятие предметной области. Я отписался в предыдущем посте об этом.

T>>Ну не надо Фаулера уж совсем за идиота считать. Понятно же, что анализ/моделирование присутствует всегда.
S>Пока что непонятно. Ты очень ловко манипулируешь понятием "domain model". В итоге, она моделирует всё, что угодно. Как у Лема про сепульки.
S>Так всё-таки, что именно моделирует domain model? К чему она должна быть близка?

Тут все просто. Следите за руками
Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.

S>Мне как-то не хочется пользоваться термином, определенным через самого себя.

Это разные domain: первый — концептуальный (результат анализа), второй — программная реализация первого.

T>>Ест такие понятия. Только формулируются они не как "существительные", а как некоторые правила, ограничения.
S> И какие же правила в предметной области соответствуют DACL?

Пользователь, ассоциированный с указанным кастомером не должен иметь возможности резервировать остатки на складе №555.

T>>Для них нет "физического" представления в предметной области, но есть концептуальное.
S>Что такое "концептуальное представление"?

Результат анализа.

T>>Ты очень правильно выделил "в таком". Но из того, что "в таком виде малопригодно" не следует, что ООП само по себе непригодно.
S>Никто и не протестует против ООП вообще. Просто в бизнесе полиморфизм оказывается применим не к данным, а к сервисам.

Не надо приравнивать ООП к полиморфизму. Оно полиморфизмом не ограничивается, есть еще как минимум инкапсуляция, aka сохранение инвариантов.

S>Применять всю мощь ООП к данным — примерно то же самое, что одушевлять бухгалтерские проводки

К данным вообще не нужно применять мощь ООП, а вот к сущностям — .... см. выше

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

T>>Так изменения и у тебя расползаются. Инварианты же тебе все равно придется проверять во всех своих сервисах/менеджерах. Где преимущество?
S>Э нет. Тут фишка в том, что за формулировку "инвариантов" отвечает один класс, а за проверку — разные.
S>К примеру, UI запрашивает у бизнеслогики набор правил валидации, благодаря чему пользователь получает "упс" не дожидаясь коммита.
S>При этом само по себе правило записано ровно один раз.

Я как раз по этому поводу отписался gandjustas-у.

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

Совершенно верно. Но тем не менее она будет нужна в обоих случаях.
Поэтому тот факт, что авлидация поменялась 5 раз за два дня, не является аргументом ни за, ни против domain model.

T>>Тебя смущает,. что файл, в котором лежит объявление атрибутов сущности, меняется или что-то еще?
T>>Если первое, то это легко решить при помощи тех же partial-классов (C#).
S>Не вижу ничего легкого.

Так тебя именно это смущало или есть что-то еще?

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

T>>Ну так и в domain model не особо сложнее: entity, service, repository, ...
S>Непонятно, по каким критериям распределяется логика между entity, service и repository.

Да все понятно.
Для entity: те методы, которые относятся только к самой этой entity.
Для сервиса: сложные операции, затрагивающие "многое"
Репозиторий — взаимодействи с хранилищем.

T>>То есть меняем мы не только в соответствующем менеджере, но и в сервисах?
S>Что именно меняем?

Есть ReservationService. Как мы предположили, он списывает остатки, и обновляет строки резервируемого заказа (прописывает сколько было зарезервировано). Соответственно ответ на твой вопрос — меняем остатки на складе и кол-во зарезервированного товара в заказе.

T>>На проверку того, что этот номер указан у кастомера
S>Ок, то есть мы с трудом придумали неубедительный пример с not null инвариантом. Как и следовало ожидать,
S>а) этот пример достаточно сомнительный. В том смысле, что дальнейший анализ запросто может привести к тому, что в реальных сценариях нам нужно разрешать работу с кастомером еще до того, как его "номер" будет доступен
S>б) это настолько мягкий инвариант, что большую роль ему придавать я бы не стал. Ну то есть он же ничего не говорит ни о структуре этого номера, ни о том, что он соответствует какой-то реальной записи в бухгалтерской программе, ни, тем более, о том, что по этому номеру там заведен именно этот кастомер, а не просто сделана ошибка.

Все эти вопросы/сомнения — out of scope разработки. Это относится к анализу, поэтому в качестве аргумента за/против rich model они не очень подходят.

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

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

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

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

G>>domain model по фаулеру и есть dataobjects+"какое-то мифическое поведение".

T>Я вчера не поленился и бегло посмотрел Фаулера. Он ссылается на книжку Эванса, которая на момент публикации PoEA не была доступна. Сейчас он уже несколько лет как ледит в магазинах. Там DDD расписан более подробно.

G>>А расползание вы получите при первом же изменении бизнес требований.
G>>например рассмотрим ввод данных. Раз у вас "сущности" не байндятся на контролы, то валидацию в процессе ввода вы получить не сможете. Поэтому вам придется продублировать логику валидации в UI, чтобы сделать хороший фидбэк.
G>>Если у вас меняется логика валидации, то вам уже надо менять в двух местах.

T>Есть и другой вариант — логика валидации лежит во внешнем классе, а при изменении сущности этот внешний класс пользуется сущностью. И получили руюз.
Не будет реюза. Как UI узнает что конкретного текстбокса нужно применить конкретное правило? А если UI автоматически генерируется для разных типов сущностей?
Будет реюз самих проверок, типа длина строки меньше X и соответствует regexp Y.

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

T>Тут все просто. Следите за руками
T>Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
T>Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.
Ок, прекрасно. А что является результатом анализа?


T>Пользователь, ассоциированный с указанным кастомером не должен иметь возможности резервировать остатки на складе №555.
Ух, как интересно. Вообще-то, здесь нет никакой произвольности. Напомню, что DACL — это discretionary access control list.
Поэтому наиболее близкой к такому результату анализа является модель, в которой так и зашито "если работаем под пользователем, который ассоциирован с указанным кастомером, то выбросить склад №555 из рассмотрения".

Никаким DACL тут и не пахнет.

T>Результат анализа.
Ок. Сепульки — результат сепуления. В таком стиле мы далеко не уедем.

T>Не надо приравнивать ООП к полиморфизму. Оно полиморфизмом не ограничивается, есть еще как минимум инкапсуляция, aka сохранение инвариантов.
Ок. Не будем.
Почитай вот здесь.
Сильно помогает правильно расставить акценты.

S>>Применять всю мощь ООП к данным — примерно то же самое, что одушевлять бухгалтерские проводки
T>К данным вообще не нужно применять мощь ООП, а вот к сущностям — .... см. выше
Продолжаю непонимать, какой смысл в замене данных сущностями.

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

T>Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
T>Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.
Результаты анализа обычно составляют:
1)Описания сущностей и свзязей — ER модель
2)Описания бизнес-правил — валидация модели
3)Описания бизнес-процессов — действия, которые производятся над моделью
4)Описание ролей — ограничение доступа к процессам и их частям

Как из этого получаются объекты с поведением?

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

T>>Есть и другой вариант — логика валидации лежит во внешнем классе, а при изменении сущности этот внешний класс пользуется сущностью. И получили руюз.
G>Не будет реюза. Как UI узнает что конкретного текстбокса нужно применить конкретное правило? А если UI автоматически генерируется для разных типов сущностей?

Ну это уже как сделаешь, это вопрос технический.

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

T>>Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
T>>Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.
S>Ок, прекрасно. А что является результатом анализа?

Концептуальная модель.

T>>Пользователь, ассоциированный с указанным кастомером не должен иметь возможности резервировать остатки на складе №555.
S>Ух, как интересно. Вообще-то, здесь нет никакой произвольности. Напомню, что DACL — это discretionary access control list.
S>Поэтому наиболее близкой к такому результату анализа является модель, в которой так и зашито "если работаем под пользователем, который ассоциирован с указанным кастомером, то выбросить склад №555 из рассмотрения".
S>Никаким DACL тут и не пахнет.

Не забывай, что DACL — это не только пользователи, но и группы. Вот как раз по кастомерам пользователи и группируются. Я же специально написал "ассоциированный с указанным кастомером"

T>>Результат анализа.
S>Ок. Сепульки — результат сепуления. В таком стиле мы далеко не уедем.

А что ты от меня хотел бы услышать? Формат оформления документов? В этом я увы не силен.

T>>Не надо приравнивать ООП к полиморфизму. Оно полиморфизмом не ограничивается, есть еще как минимум инкапсуляция, aka сохранение инвариантов.
S>Ок. Не будем.
S>Почитай вот здесь.
S>Сильно помогает правильно расставить акценты.

Прочитал: "HTTP/1.1 403 Access Denied." Действительно, просветление снизошло.

S>>>Применять всю мощь ООП к данным — примерно то же самое, что одушевлять бухгалтерские проводки
T>>К данным вообще не нужно применять мощь ООП, а вот к сущностям — .... см. выше
S>Продолжаю непонимать, какой смысл в замене данных сущностями.

Продолжаю повторять — сохранение инвариантов.

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

T>>Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
T>>Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.
G>Результаты анализа обычно составляют:
G>1)Описания сущностей и свзязей — ER модель
G>2)Описания бизнес-правил — валидация модели
G>3)Описания бизнес-процессов — действия, которые производятся над моделью
G>4)Описание ролей — ограничение доступа к процессам и их частям

G>Как из этого получаются объекты с поведением?

Замени "ER модель" на сущности domain model, а "валидация модели" — на constraint-ы

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

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

T>>>Есть и другой вариант — логика валидации лежит во внешнем классе, а при изменении сущности этот внешний класс пользуется сущностью. И получили руюз.
G>>Не будет реюза. Как UI узнает что конкретного текстбокса нужно применить конкретное правило? А если UI автоматически генерируется для разных типов сущностей?

T>Ну это уже как сделаешь, это вопрос технический.

Это вопрос дизайна.

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

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

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

G>Чтобы такое можно было сделать каждый объект должен уметь отавать описание валидации.
G>Этого можно добиться двумя способами: а)интерфейсом, но тогда надо корректно инстанцировать это описание, ведь объект может создаваться явно, через конструктор, и неявно — маппером. б)внешним описанием — атрибутами, xml или чем-то еще и получать это описание по некоторому индентификатору, которым обладает объект (самое простое — по типу).
G>Самим процессом валидации объекта по соответствующему описанию должен заниматься какой-то сервис.

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

Какие проблемы, если валидатор получаем например по типу сущности?

G>А также приседания при необходимости отключить валидацию и прочее.

Не надо ее отключать.

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

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

T>>>Есть бизнес. Есть анализ этого бизнеса. Есть программы, нацеленные на облегчение ведения бизнеса.
T>>>Так вот, DDD относится к третьему этапу. Основной постулат DDD — это что модель, используемая в программе должна максимально соответствовать результату анализа.
G>>Результаты анализа обычно составляют:
G>>1)Описания сущностей и свзязей — ER модель
G>>2)Описания бизнес-правил — валидация модели
G>>3)Описания бизнес-процессов — действия, которые производятся над моделью
G>>4)Описание ролей — ограничение доступа к процессам и их частям

G>>Как из этого получаются объекты с поведением?

T>Замени "ER модель" на сущности domain model, а "валидация модели" — на constraint-ы

И что от этого изменится. Указанные выше 4 пунтка как были ортогональны друг другу, так и останутся.