Один маршрут веб-API, который требует нескольких служб

Question

Я создаю сайт, который использует рабочие процессы.По сути, рабочий процесс может иметь задачи, а также историю всего, что произошло в рабочем процессе.Когда кто-то назначает задачу кому-либо еще через пользовательский интерфейс, должны произойти две вещи:

• Задача должна быть назначена новому уполномоченному
• Должна быть создана запись истории рабочего процесса

Итак, для этого у меня есть веб-API «TaskController» с маршрутом «Назначить», который ожидает идентификатор задачи и новое имя пользователя для назначенного.

Теперь я не знаюкак именно поступить.Действительно, у меня есть «TaskService», и я мог бы добавить в него метод «Назначить», но я не совсем уверен, что этот метод должен делать.Я уверен, что нужно назначить задачу, но как насчет создания истории рабочего процесса?Для меня это ответственность "WorkflowService", чтобы сделать это.Более того, могут быть случаи, когда я не хочу создавать историю, но, поскольку я использую «TaskService», она всегда будет делать это (за исключением того, что я добавляю в метод параметр «createHistory», но я нея не хочу этого делать).

Другое решение, которое я имею в виду, заключается в том, чтобы вызывать эти разные службы в маршруте Web API.Примерно так (в псевдокоде):

_taskService.AssignTask(...);
_workflowService.CreateHistory(...);

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

using (_dbContext.Transaction) {
   _taskService.AssignTask(...);
   _workflowService.CreateHistory(...);
}

Это бы сработало, но я чувствую, что для маршрута Web API много логики ...

Я некоторое время гуглял и не нашел ничего, что помогло бы мне принять решение.Для меня служба должна выполнять только определенные действия, поэтому «TaskService» не должен добавлять запись истории рабочего процесса.Однако в маршруте веб-API не должно быть большой логики (поэтому он не должен создавать транзакцию).

Кто-нибудь знает шаблон или что-то, что могло бы помочь мне в этом?

Answer 1

В вашем сценарии вы можете создать историю двумя способами

1. Используя триггеры базы данных
2. Переопределив метод DatabaseContext.Save () для объекта задачи в репозитории EF

Таким образом, вам потребуется только один вызов «_taskService.AssignTask (...)» из вашего метода Web API, и история будет создана.Выбор метода аудита будет зависеть от архитектуры вашего приложения (т. Е. От того, как вы создали свои сервисы и репозитории, ваши сущности и т. Д.).Если дизайн вашего приложения не слишком сложен, любой из двух вышеуказанных методов будет работать без проблем.

Answer 2

Вы задаете вопрос, на который нельзя ответить окончательно.Все зависит от того, как вы хотите создать свое приложение, и, таким образом, решение может принимать только вы.Здесь нет жесткого и быстрого правильного или неправильного.

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

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

Что касается шаблонов, то микросервисная архитектура - это в основном то, что вы строите здесь, только без создания отдельных приложений.Однако следование истинной архитектуре микросервисов заставит вас по-настоящему разграничить сферу ваших услуг.Если вы посмотрите на шаблон, вы увидите, что каждый микросервис представляет собой отдельную единицу функциональности, но ему не запрещено взаимодействовать с другими службами для координации работы.Например, службе корзины может потребоваться работа со службой инвентаризации и службой ценообразования.Это все еще делает только одно: управление тележками.Тем не менее, есть другая работа, которая должна быть выполнена, - работа, за которую отвечают другие службы.Поэтому они должны координировать свою работу, чтобы выполнить работу.