Где разместить доменную логику, которая должна извлекать данные из базы данных - PullRequest
7 голосов
/ 15 мая 2011

Я знаю, что логика домена должна быть помещена в объекты домена.Но что, если моей доменной логике нужны данные из базы данных?(например, проверка уникального значения, вычисленных значений и т. д.) Я думаю, что внедрение репозиториев в мои доменные объекты не является правильным.Также уровень обслуживания не должен содержать бизнес-правил.Так как же решить эту бизнес-логику?

Ответы [ 2 ]

3 голосов
/ 15 мая 2011

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

Есть несколько способов сделать это:

  • сервисный уровень предварительно загружает любую информацию, которая потребуется объекту домена
  • объект домена может вызывать помощника или хранилище, которое получает данные из базы данных
1 голос
/ 16 мая 2011

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

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

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

Что я делаю, так это размещаю саму «логику» в домене, обычно в форме реализации шаблона спецификации. Поскольку логика выполняется в хранилище и не требует изменения уровня обслуживания, я смирился с тем, что это вполне приемлемо. Вы обнаружите, что правила, которые применяются к коллекциям сущностей, обычно являются «забавными». Если вам нужно только удостовериться, что что-то уникальное в коллекции в корневом корне, это достаточно просто.

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

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