Архитектура микросервисов и отрыв от монолитного приложения

Question

Я собираюсь начать процесс разбивки нашего устаревшего приложения (построенного поверх EpiServer CMS). Мы хотели бы разбить его на более мелкие, более управляемые компоненты (микросервисы). Я склоняюсь к NServiceBus и некоторому типу модели домена. Какие инструменты могут мне помочь? С чего бы начать? Есть ли что-нибудь, что может помочь мне определить разные точки абстракции?

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

Answer 1

Как правило, я бы советовал делать так много работы с устаревшими приложениями, если все вовлеченные стороны не понимают, что вы делаете полную перестройку.

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

Как только вы определили, какую проблему вы пытаетесь решить, тогда разрежьте ее на мелкую кусочку, которая имеет смысл (для микросервисов), а затем вы можете начать определять свою модель домена (ddd). Например, создайте отдельную службу отчетов для создания еженедельного отчета. Затем попробуйте решить, действительно ли это решение вашей проблемы. добавьте 2 месяца ко всем вашим оценкам и проверьте, хочет ли бизнес это сделать.

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

Update2 DDD отлично подходит, когда общение является большой проблемой. Когда есть сложный бизнес-домен и или когда разработчики часто (слегка) неправильно истолковывают то, что хочет бизнес.

Microservices - отличный инструмент, когда вам нужно масштабировать. Это также помогает, когда вы хотите часто тестировать новые вещи. Однако поддерживать и отлаживать ваши события может быть настоящей болью. И будьте осторожны, когда вам нужно складывать/агрегировать события (мне нужно, чтобы X произошел, если событие A & B оба подняты в определенном потоке)

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

ОБНОВЛЕНИЕ и решить настоящую проблему. не добавляйте что-то слишком простое и используйте его, чтобы ввести служебную шину (или другую крутую технологию x). Если вам нужно масштабирование, то решите проблему, которая на самом деле требует масштабирования.