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

Question

я работаю над приложением N-слоистые .NET со следующими слоями:

• Presentation
• Применение
• домена
• Инфраструктура (Содержит Постоянство и общие вспомогательные функции, такие как электронная почта)

в какой-то момент в моей APPLICAT ион, запрос одобрен. После утверждения необходимо выполнить 4 этапа следующим образом:

1. Присвоить код тега продукта выпущенному продукту в запросе.
2. Обновить статус запроса от «Обрабатывается» в «Order Completed»
3. Отправить по электронной почте запрашивающей с указанием их продукт готов к пикап
4. Отправить по электронной почте менеджеру реквестера информируя их о чем их работник был дан и копия запроса они одобренным для продукта

Вышеуказанные шаги должны быть частью атомарной операции означает, что они должны все быть сделано или действие отменяется. я имею в виду иметь прикладной уровень направляет запрос Repository и Persistence Layer выполнять следующие задачи:

1. запросов Application Layer для Repository запрос на выполнение шаги 1 и 2 в качестве единицы работы транзакции
2. запросы прикладного уровня для слоя инфраструктуры выполнять шаги 3 и 4.

Я не совсем уверен, что если Application Layer должен это сделать. Я думаю, это потому, что первые 2 действия требуют обращения к репозиторию, которого я избегал делать на уровне домена. Последние 2 шага включают в себя уровень инфраструктуры, с которым может взаимодействовать уровень домена через экземпляр, введенный в зависимость. Следуя этой логике, уровень приложения не требует, чтобы слой домена ничего не делал. Является ли это, как правило, для многоэтапного процесса, подобного этому, когда у вас есть Application Layer? Или я что-то пропустил?

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

Заранее спасибо.

Answer 1

Шаги 1 и 2 в вашем вопросе звучат как логика домена для меня. Так что нет, это не нормально. Эти два этапа должны быть выполнены в домене. Вы можете сделать следующее:

1. В службе приложения, загрузите соответствующий агрегат (вероятно Request).

2. Либо вызвать операцию, которая делает шаг 1 и 2 на Request, или (если операция на самом деле не принадлежат к Request) вызвать службу домена, который выполняет эти два шага.

3. Как только операция домена будет завершена, служба приложения может сохранить измененный Request обратно в БД.

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

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

Как было предложено plalx в комментарии, отправка электронной почты может быть выгружена потребителю событий домена, если у вас есть инфраструктура событий. Это обычно решает механизм повторной попытки бесплатно.