Архитектура приложения с API NServiceBus и REST

Question

Мы работаем над заменой нашей старой VB6-системе, использующей SQL-сервер. Большая часть бизнес-логики находится в хранимых процедурах и триггерах. В настоящее время мы имеем некоторые функции NServiceBus, используя триггеры в базе данных для размещения сообщений в очереди (SQLTransport).

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

Новый интерфейс вызовет REST api для извлечения данных. То, с чем я борюсь, - это лучшие практики, выполняющие операции, которые создают/обновляют/удаляют данные. Для автоматизированных процессов, которые не требуют немедленного ответа, они могут просто отправить команду по шине. Однако для конечных пользователей, которые будут использовать приложение, они ожидают немедленных результатов. Если что-то вызывает сообщение в FLR/SLR, очевидно, что клиент не может сидеть там, ожидая чего-то.

Одна из идей - иметь библиотеку, которая обрабатывает все вызовы в базу данных, которые могут использовать как API, так и любые обработчики сообщений NServiceBus. Проблема, которую я вижу, - это когда операция должна публиковать событие. Из обработчика сообщений можно просто публиковать сообщение. Если я обрабатываю простую команду из REST api, я не могу просто опубликовать одно и то же событие (так как ничто не подписывается на REST api, и это может быть

Одним из решений может быть предоставление REST api send (не публиковать) сообщение конечной точке (тот, на который подписаны другие конечные точки), который затем опубликует событие всем подписчикам.

Как другие реализуют что-то вроде этого? Основные случаи использования, которые я думаю из простых операций create/update/delete, которые клиент ожидает от результатов в реальном времени, но бэкэнду, возможно, потребуется опубликовать событие, указывающее на то, что что-то произошло.

Answer 1

Что вы описываете, является ch allenge, и я не буду пытаться предоставить решение здесь, однако, пару указателей ...

Синхронная связь (запрос/отклик на том же канале) является ортогональным для обмена сообщениями, стиль обмена сообщениями является огнем и забыт.

Концепция CQS (Command Query Separation), когда операции изменения состояния не отвечают данными измененного состояния, операции считывания, поэтому выполняются на отдельном канале, являются хорошим руководством для построения систем, использующих обмен сообщениями.

Также я бы избегал использовать обмен сообщениями для операций чтения (используйте прямой ADO).

CRUD-операции - это запах (я понимаю, что это устаревшая база кода), поскольку эти операции скрывают любые намерения или ценность для бизнеса.

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

Я был бы счастлив иметь более глубокий обсуждение (напишите мне sean.farmar на specific.net)