Фейсбук напомнил о написанном 5 лет назад :) Легаси Стрит :)
Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»
Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?»