Богатая модель домена и ORM

Мартин Фаулер рассматривает модель анемического домена как анти-шаблон.

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

Итак, нам нужен DomainModel, который основывается на модели сохранения (вместо того, чтобы быть одним и тем же). Затем эта модель домена будет содержать свойства и метод бизнес-логики.

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

Мы делаем такие мужественные отображения здесь.

Стойкость к модели домена
Чтобы преобразовать модель домена в DTO для передачи между службами

На этом не заканчивается, так как DTO может быть отображен в ViewModel.

Все это и проблема дублирования логики проверки по-прежнему не исчезают, потому что клиент хочет проверки в реальном времени. ViewModel ничего не знает о проверке, поэтому в SPA, например, вы вынуждены снова переписать логику проверки на стороне клиента (обычно в javascript).

Кроме того, службы по своей природе не имеют статуса (сообщения или RPC-ориентированные), поэтому мы делаем все это сопоставление между Persistence, OO, а затем обратно в процедурный, в какую пользу? Как бы вы оправдали стоимость в практическом плане большинства ИТ-бюджетов?

Получаю, как бы полное DDD, с Aggregate Roots, Domain Models и т.д. было бы "круто", но как вы можете оправдать стоимость и хит производительности dev?

анти-шаблон (или антипаттерн) - это шаблон, используемый в социальном или деловом операций или разработки программного обеспечения, которые могут неэффективным и/или контрпродуктивным на практике

И если это так, не будет ли DDD и Rich Domain Model входить в определение анти-шаблона выше, чем модель "Lean" Domain. Извините, я презираю загруженное слово "Anemic".

Сохраняя модель домена "Lean", вы фактически разрешаете ее делиться без нарушения "принципа абстрактной зависимости", "Do not Repeat Yourself" и трудоемкого, утомительного и подверженного ошибкам процесса отображения одного носителя данных к другому, и независимо от того, что связано с Unit Test, что происходит поверх этого (если вы не собираетесь делать сопоставление без модульного тестирования и надеетесь на лучшее).

Ответ 1

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

Богатая модель домена является ортогональной многоуровневой архитектуре, особенно если модель богатого домена не определяет количество слоев, которые у вас есть, какие структуры данных следует обменивать между этими уровнями и как они должны отображаться.
Богатая модель домена ортогональна проверке и ничего не говорит о необходимости проверки на стороне клиента в дополнение к проверке на стороне.

Другими словами, превращение вашей модели домена в анемию со всей бизнес-логикой в сервисах не обязательно избавит вас от написания большого количества кода картографирования кода DTO и не будет устранять необходимость "двойной проверки" на стороне клиента (которая кстати, является общепринятой лучшей практикой).

Это не означает, что ваша оценка стоимости и веса полноценной многоуровневой архитектуры недопустима. Вы можете найти интерес к этому сообщению Марк Семанн, обсуждая похожие проблемы: http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx

Ответ 2

tl; dr Модель домена не определена, она, вероятно, разработана с учетом принципа db.

Основными целями DDD являются моделирование в коде концепций и процессов бизнеса. Я действительно сомневаюсь, что ваши бизнес-концепции и процессы - всего лишь мешки свойств. Но если они действительно являются да, модель домена может быть такой же, как и модель Persistence, поэтому вам не нужно делать какие-либо сопоставления.

Модель модели persistence описывает, как состояние объекта сохраняется. Если вы не находитесь в домене баз данных, то модель домена и персистенции не может иметь такую же цель. Одна из самых больших ошибок, которые я вижу с DDD, - это думать о модели домена, как о том, что все еще управляется данными. В DDD у вас нет конкретной базы данных. У вас есть хранилища. Не существует отношений "один-ко-многим", "многие-ко-многим" и т.д. Нет таблиц и строк. Есть только объекты, которые пытаются представить Домен как можно точнее.

Проще говоря, Domain заботится о моделировании бизнес-поведения, в то время как Persistence заботится о сохранении состояния объекта. Здесь я вижу две разные обязанности.

О проверке, у вас есть 2 типа: проверка входных данных формат, а затем проверка других бизнес-правил в соответствии с тем, что вы изменяете в состоянии объекта.

О дублировании, я думаю, вы имеете в виду формат ввода, но, как @EbenRoux, есть механизм, который может помочь в этом. В asp.net mvc большинство этих правил проверки имеют также версию js.

Позвольте мне рассказать вам немного секрет с услугами. В то время как их интерфейс может быть определен в Домене, их реализация может находиться в Уровне сохранения, что позволяет им работать непосредственно с хранилищем. А поскольку остальная часть приложения использует сервис в своей абстрактной форме (интерфейсе), только контейнер DI будет знать секретный секрет.

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

Как это звучит, вам нужен кирпичный дом, но конструктор говорит: "Извините, но моя пила работает только с деревом". Ну, не используйте пилу, используйте другой инструмент, который поможет вырезать кирпич. Инструменты должны быть адаптированы к проблеме, а не наоборот.

Ответ 3

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

Другая часть - это весь бизнес картографирования:)

То, что вы делаете, эффективно используется для выполнения чтения. Возможно, вы думаете, что вам нужно прочитать свою сущность для ее редактирования. Это верно, если вы выполняете операции на основе сущности (сущность, скорее всего, больше в терминах БД здесь - целая запись), а не на основе задач на объекте объекта. Глупым примером может быть то, что клиент звонит в центр обработки вызовов, чтобы изменить адрес. Оператор вызывает запись клиента и редактирует адрес. Это основано на сущности и приводит к типичным проблемам w.r.t. concurrency, так как 2 действия могут выполняться на одной записи (однако маловероятно). Это очень традиционный подход к дизайну UX: "Редактируйте запись".

Контрастируйте это с помощью кнопки на экране, которая гласит: " изменить адрес". Вы только меняете адрес на записи, и хотя это похоже на то же самое, на самом деле это совсем другое. Шансы на 2 операции, которые меняют один и тот же адрес, скорее более тонкие, чем изменение одной и той же записи. При необходимости concurrency проверка может быть выполнена с этой стороны.

Теперь, если вы не читаете домен, что бы прочитать. Откуда берутся данные. В это время появляется CQRS ( "Сегрегация ответственности команд/запросов" ). В прошлом он был запутан/объединен с Event Sourcing, но это не требуется. Вы можете создать простую сторону запроса в своем приложении, ориентированную на возвращение необходимых вам данных. В С# я использовал DataRow, если это один экземпляр, DataTable для нескольких экземпляров и пользовательский DTO для чего-то более сложного. Может быть, есть способ уйти от анонимных типов (еще не исследовать это).

Таким образом:

Модель домена = операции/расчет/запись Службы запросов = читать

Есть ситуация, когда вы можете уйти просто с загрузкой сущности/агрегата, например, в веб-приложение, поскольку оно известно (или может быть известно) о вашей модели домена, но умный клиент будет немного анти- шаблон.

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

DDD - это не только техническая реализация, хотя это идет долгий путь, продвигаясь в направлении правильного моделирования OO. Я полагаю, что другие идеи все равно попадают в программное обеспечение, поэтому программное обеспечение, по-видимому, все равно сосредоточено. Мы все хотим увидеть, где резина встречает дорогу.

Как и большинство DDD, это может быть сделано неправильно:)