DDD Специфичная для домена / Общая Инфраструктура - PullRequest
Новая
       26

DDD Специфичная для домена / Общая Инфраструктура

0 голосов
/ 03 ноября 2011

Что касается доменной инфраструктуры, можно ли думать о них как о:

  • Общие сведения: как отправить электронное письмо / прочитать файл конфигурации и т. Д.
  • Определенно: как отправитькод активации для нового пользователя (сущности домена)

Где, если я думаю о зависимостях:

  • Домен <Ссылки> Общая инфраструктура (для ведения журнала, общих исключений и т. Д.)

  • Специальная инфраструктура <Ссылки> Общая инфраструктура и домен (чтобы получить интерфейсы операций, связанных с инфраструктурой, такие как IActivationCodeSender и иметь возможность реализовать EmailActivationCodeSender & SmsActivationCodeSender )

Мой прикладной уровень в этом случае будет ответственным за передачу (DI разрешено) желаемого метода активации в мою сущность домена, скажем: 

User.Register(IActivationCodeSender activationCodeSender)
{
   // Register user and generate activation code 1234
   ...
   activationCodeSender.Send(this, "1234");
}

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

Две (общие) реализации для INotificationSender ; EmailNotificationSender и SmsNotificationSender 

User.Register(INotificationSender activationCodeSender)
{
   // Register user and generate activation code 1234
   ...
  // this.NotificationAddressInfo includes email address and mobile phone #

   activationCodeSender.Send(new Notification(this.NotificationAddressInfo, "Your activation code is 1234"));
}

Ответы [ 3 ]

1 голос
/ 11 января 2012

Я бы посоветовал вам рассмотреть возможность использования принципа обращения зависимостей , который имеет следующие основные принципы (из Википедии):

  1. Модули высокого уровня не должнызависит от низкоуровневых модулей.Оба должны зависеть от абстракций.
  2. Абстракции не должны зависеть от деталей.Детали должны зависеть от абстракций.

Поэтому я бы поместил все интерфейсы, такие как IActivationSender, в ваш домен, а затем внедрил бы этот интерфейс в отдельный инфраструктурный проект.Как вы упомянули, используйте DI для внедрения нужной реализации в службу приложений (или в службу домена).

Таким образом, вы можете избежать использования шаблона диспетчеризации двойных пар , где вы передаете реализациюинтерфейса непосредственно к domain entity:

User.Register (INotificationSender ActivationCodeSender)

И вместо этого есть что-то вроде:

UserService.Register(user);

Где UserService может быть доменной службой с введенным правильным INotificationSender.

Совершенно другим способом решения проблемы может быть использование событий домена (см. статья Udi Dahans ).Следуя этому шаблону, ваша сущность User вызовет событие «UserCreated», на которое, в свою очередь, подпишется INotificationSender.Таким образом вы избавляетесь от необходимости отправлять уведомления от сущности User.

0 голосов
/ 09 ноября 2011

Нет доменной инфраструктуры.
Вашему клиенту все равно, как вы собираетесь отправлять электронную почту.

0 голосов
/ 04 ноября 2011

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

...