Где включить бизнес-логику в архитектуру, управляемую доменом

Question

Я пытаюсь изучить эффективные методы DDD, но у меня возник фундаментальный вопрос, который я хотел бы прояснить.

Я использую веб-формы ASP.NET и создаю ситуацию, когдаПользователь размещает заказ.После отправки заказа выделенный код извлекает пользователя, формирует заказ из входных данных в форме, вызывает метод User.PlaceOrder (), чтобы выполнить добавление объекта заказа в коллекцию заказов пользователя, и вызывает хранилище для сохранения записи.в базу данных.Это довольно просто и понятно.

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

Спасибо за вашу помощь!

Answer 1

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

Я разбил свою логику на три части, по большей части:

• Логика сущности
• Логика доменной службы
• Логика службы приложений

Логика приложения - это, где я регистрирую, например, события домена.Я не думаю, что электронная почта относится к домену, лично.Это требование, а не кусок логики.Если у меня есть прослушиватель в этот момент, домен может вызвать событие OrderSubmitted (), и прослушиватель несет ответственность за его действие.Событие относится к домену, поскольку оно описывает значительное событие в контексте домена.Однако, как приложение реагирует на это, на мой взгляд, все по-другому.

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

Answer 2

Отправка письма с подтверждением лучше всего делать асинхронно после того, как заказ будет сохранен в базе данных.Я бы представил некоторую шину сообщений (например, NServiceBus) для обработки такого случая.В той же транзакции, что и при сохранении заказа, вы публикуете в шине сообщение «Заказ был создан».Это обработчик, который подписывается на это сообщение и отправляет электронные письма клиентам.

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

Answer 3

Что я делаю, так это представляю логический уровень для всей логики, которую кодовый код предназначен только для обработки запросов, а хранилище предназначено только для грубых операций. Таким образом, вы отлично отделили логику от остальной части приложения и легко тестируются *