Валидация уровня сервиса или валидация объекта домена; потенциальное "злоупотребление" объектами домена?

Question

Я видел много примеров книг и статей, в которых говорилось о том, чтобы поместить код проверки в ваш уровень обслуживания.Держите Объекты Домена "тупыми" (иначе говоря, чистые POCO) и обрабатывайте всю проверку, которую Доменный Объект мог бы сделать на Сервисном Уровне.

Сервисный Уровень ответственен за так много, как кажется (или, по крайней мере, может)быть);аутентификация пользователя, аутентификация роли, скриптовые объекты зависимостей для IoC (логгеры, обработчики ошибок и т. д.), скриптовые доменные объекты, скриптовые репозитории и передача доменных объектов в и из хранилища ... вот так!

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

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

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

Если не существует способа «заблокировать» Объекты Домена, то почему так много статей, книг и т. Д. Предлагают использовать проверку Доменных Объектов на Сервисном Уровне?Я бы предположил, занимая оборонительную позицию программирования, что вы должны создать свои доменные объекты, чтобы они были пуленепробиваемыми, и полагаться на свой уровень обслуживания для простого слоя кода для пересылки и получения запросов между пользовательским интерфейсом и BAL / DAL.

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

Answer 1

Я думаю, вы можете неправильно понять цель POCO. Как я понимаю, POCO - это не анемичный объект предметной области, имеющий только свойства и атрибуты. Скорее POCO просто не привязан к каркасу или сложной модели наследования. Объект является гибким и касается только своей роли в домене.

Answer 2

Это две разные философии дизайна.Модель богатых доменов против модели анемичных доменов.

Короткий ответ: да, вы можете запретить прямой доступ к объектам вашего домена.

Вы можете сделать это несколькими способами:

1) Вы можете сделать всеобщедоступные доменные объекты неизменяемы (то есть вы не можете изменять данные), используя только общедоступные методы для получения.Все методы, которые изменяют ваши объекты, могут быть защищены или упакованы как закрытые, так что только правильно упакованные сервисы могут получить к ним доступ (по крайней мере, в Java)
2) Вы можете предоставлять только отдельные классы внешним разработчикам - так что если у вас есть PersonКласс домена. У вас может быть класс PersonInfo, который вы пропускаете и который ничего не делает, кроме как содержит информацию.
3) Вы должны предоставить целостный API потребителям вашего приложения.По сути, вы не позволяете им обойти ваш уровень обслуживания.