Как создать богатые доменные объекты, сохраняя постоянное невежество? - PullRequest
6 голосов
/ 01 июня 2011

Во-первых, я использую веб-формы без какой-либо платформы ORM.

Я боролся с тем, как сделать мои доменные объекты настолько «умными» и «богатыми», насколько они могут быть, не позволяя им получить доступ к моему сервису и уровню хранилища. Моя последняя попытка была в создании модели для подарочных сертификатов для интернет-магазина.

Основные повторяющиеся проблемы, с которыми я сталкиваюсь, это:

  • Все больше и больше логики внедряется на уровне сервиса. Все обращения к хранилищу должны проходить через уровень обслуживания, и каждый раз параметры проверяются (например, существует в БД и т. Д.). В результате уровень моего сервиса растет, но мои доменные объекты просто проходят некоторые договорные проверки. Даже проверка объекта находится на сервисном уровне, так как, если идентификатор элемента равен нулю, он проверит БД, чтобы убедиться, что код уникален. IHMO, потребитель системы не должен заботиться о том, справляется ли ему необходимая функциональность с постоянством или нет.

  • У меня есть отдельное POCO для записей в журнале транзакций на случай, когда подарочный сертификат погашен. Я предполагаю, что должен поместить список или коллекцию этих транзакций в качестве свойства моей модели Подарочного сертификата, но я все еще не уверен, когда это свойство должно быть заполнено. Добавлять ли в сервис отдельный метод для загрузки транзакций в объект по требованию (например, LoadTransactions (объект gc)), или если транзакции будут автоматически загружаться каждый раз, когда запрашивается существующий подарочный сертификат или список подарочных сертификатов (или, возможно, опция в getGCs также для загрузки транзакций)

  • А как насчет вычисляемых полей, таких как «Доступный баланс» ... у меня даже должны быть такие свойства на моем объекте? Каждый раз, когда я работаю с объектом, мне нужно будет постоянно обновлять это свойство, чтобы обеспечить его актуальность. Прямо сейчас у меня просто есть метод сервиса GetBalanceByCode (gc code).

  • Даже такие действия, как погашение подарочного сертификата, в основном на 100% ориентированы на данные (возьмите некоторые входные параметры, проверьте их и добавьте запись журнала транзакций в базу данных).

Ответы [ 3 ]

4 голосов
/ 02 июня 2011

Все больше и больше логики внедряется на уровне обслуживания (...) Даже проверка объекта находится на уровне обслуживания (...)

Проверка не является лучшим кандидатомкак элемент модели предметной области.Входные данные (мое личное предпочтение состоит в том, что они представлены в виде команд) должны быть проверены на уровне обслуживания приложения.Доменная логика должна моделировать работу бизнеса и предполагать, что все аргументы верны.Хорошими кандидатами на предметную логику являются, например, вычисления: вы хотите, чтобы они были в одном месте и чтобы они были хорошо протестированы.

У меня есть отдельный POCO для записей в журнале транзакций на случай, когда подарочный сертификат погашен.

Этот тип объекта известен как событие.О событиях можно узнать из презентации Эрика Эванса «Что я узнал со времен Синей книги» .Событие - это сущность, которая неизменна.События довольно часто объединяются сами по себе, потому что обычно их много.Делая их агрегатами, у вас не возникнет проблем с отложенной загрузкой их как части коллекции других объектов.

А как насчет вычисляемых полей, таких как «Доступный баланс» ... если у меня даже будут свойства, подобныеэто на моем объекте?

1017

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

Даже такие действия, как погашение подарочного сертификата, в основном на 100% ориентированы на данные (принимают некоторые входные параметры, проверяют их и добавляют запись в журнал транзакций в db).

Это действие будет смоделировано как создание события CertificateRedeemed.Это событие может быть создано агрегатом сертификата или каким-либо другим объектом.Это сообщение в блоге от Udi Dahan может быть полезным

3 голосов
/ 01 июня 2011

Это не совсем простой вопрос, учитывая тот факт, что доменные модели очень субъективны и во многом зависят от вашего ... ну, домена.Похоже, вы на самом деле создаете нечто похожее на The Onion Architecture Part 2 ), описанную Джеффри Палермо.Это неплохой шаблон для использования, хотя пуристы DDD скажут вам, что это приводит к «анемичным» моделям доменов (где ваши доменные объекты в основном являются держателями данных без какого-либо поведения).Дело в том, что это может быть именно то, что вам нужно в вашем сценарии.«Полная, богатая» модель предметной области может быть излишней для того, что вы делаете (и, учитывая вашу последнюю точку, кажется, что это так).

Вам может не понадобиться модель домена для вашей системы вообще.Вам могут быть полезны некоторые модели представлений (то есть простые модели данных, описывающие ваше представление), и ваш пользовательский интерфейс отправляет некоторые DTO через ваши службы для помещения данных в базу данных.Если вы найдете что-то, что требует более сложного подхода, то вы можете применить более богатую модель предметной области к этому компоненту.Также помните, что у вас не обязательно есть одна модель домена в вашей системе.Могут и во многих случаях должны быть разные модели, которые по-разному описывают вещи (часто сгруппированные в ограниченный контекст ).Общая цель DDD - упростить в противном случае сложные системы.Если это вызывает у вас дополнительную сложность, то, возможно, вы проделали долгий путь.

0 голосов
/ 01 июня 2011

Существует подход, называемый DCI (взаимодействия данных-контекста) , который должен быть альтернативой ООП старой школы.Хотя этот вопрос явно не затрагивает проблему постоянного невежества, ваш вопрос напомнил мне об этом, потому что он касается аналогичных проблем.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...