По мере того как организации переходят от монолитных приложений к небольшим автономным микросервисам, распределенные системы становятся все более детализированными. Второе дополненное издание предлагает целостный взгляд на самые актуальные темы, в которых необходимо разбираться при создании и масштабировании архитектуры микросервисов, а также управлении ею. Вы познакомитесь с современными решениями для моделирования, интеграции, тестирования, развертывания и мониторинга собственных автономных сервисов. Примеры из реальной жизни показывают, как получить максимальную отдачу от этих архитектур. Книга будет полезна всем: от архитекторов и разработчиков до тестировщиков и специалистов по эксплуатации.
Упражнение начинается с определения событий предметной области. Этим событиям, происходящим в системе, уделяется больше всего внимания. «Заказ размещен» могло бы стать событием, к которому мы проявляли интерес в контексте MusicCorp, как и «Оплата получена». Они запечатлены на оранжевых стикерах. Именно в этот момент я снова не согласен с Альберто. События — это чуть ли не самое многочисленное, что необходимо фиксировать, а оранжевых стикеров не так уж и много23. Затем участники определяют команды, вызывающие эти события. Команда — это решение, принятое человеком (пользователем ПО), за которым следует выполнение какого-то действия. В этот момент предпринимает
Наличие четких, стабильных границ сервисов, не изменяющихся при преобразовании внутренней реализации, приводит к тому, что системы получают более слабую связанность (coupling) и более сильную связность (cohesion).
Если вы видите микросервис, который выглядит просто как тонкая оболочка для CRUD-операций с базой данных, — это признак слабой связности и более сильной связанности, поскольку логика, которая должна быть в этом сервисе для управления данными, распределена по другим местам вашей системы.