Где разместить «доменные сервисы» в проекте вашей доменной модели - PullRequest
1 голос
/ 03 сентября 2010

Я работал с S # arp Architecture , но это, вероятно, применимо к любой архитектуре DDD (домен / ядро, службы приложений, инфраструктура и презентация).

ТамЕсть много примеров ASP.NET MVC, которые показывают, что контроллер работает в доменной модели через интерфейсы репозитория.Фактически, учебник по S # arp имеет StaffMembersController, ссылающийся на IStaffMemberRepository, где он вызывает FindAllMatching (реализовано в хранилище).Сущность StaffMember, также на уровне домена / ядра, выглядит как пакет данных со свойствами и минимальной проверкой свойств.

Допустим, у вас есть контроллер, который раздувается вещами, которые похожи на проблемы бизнеса.Прочитав главу Microsoft *1000* «Проектирование бизнес-структур» в Руководстве по архитектуре приложений Microsoft, я считаю, что эти проблемы можно назвать «доменными службами».

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

Спасибо!

Ответы [ 3 ]

6 голосов
/ 04 сентября 2010

То, что вы называете доменными службами в вашем вопросе, - это то, что я бы назвал прикладными службами.Этот тип путаницы в отношении трех различных типов услуг (приложения, домен и инфраструктура) приводит к тому, что термин «Задачи» используется в «Кто может мне помочь»?(вместо служб приложений).

Вообще говоря, я рассматриваю доменные службы как действия / поведения внутри домена, которые не принадлежат какой-либо отдельной сущности - это в значительной степени соответствует описанию в книге DDD Эванса.Прикладные сервисы - это скорее уровень / фасад оркестрации в домене, который позволяет приложению взаимодействовать с доменом, не требуя полной информации о том, как он работает.

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

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

Надеюсь, это поможет Джону

3 голосов
/ 03 сентября 2010

Мы создали реальную платформу электронной коммерции на основе архитектуры Sharp и создали демонстрационный проект, демонстрирующий архитектуру, которую мы внедрили.Это добавило ViewModels, Mappers и слой Task, который помогает разделить проблемы.Это сформирует основную архитектуру Sharp Architecture v2.0

Подробнее см. http://whocanhelpme.codeplex.com/.

3 голосов
/ 03 сентября 2010

Лично я не фанат того, как S # arp Architecture (по крайней мере, в своих демонстрационных проектах) контроллеры взаимодействуют напрямую с репозиториями.Мои 0,02 доллара - это то, что доменные службы должны быть интерфейсом между контроллерами и репозиториями.Репозитории существуют строго для абстрагирования базы данных (например, чтобы вы могли заменить ее, скажем, LINQ to Objects во время тестирования).Доменные службы реализуют вашу бизнес-логику.Вы хотите иметь возможность протестировать их без подключения к базе данных или макета всего сеанса.

Примером, который я считаю правильным, является проект MVC, разработанный в книге Марка Симана Внедрение зависимостей в .NET.

...