Создание микросервисов

Что вызывает необходимость тесной связанности? Классической ошибкой является выбор такого стиля интеграции, который тесно привязывает один сервис к другому, что при изменении внутри сервиса требует изменений в его потребителях. Более подробно способы, позволяющие избегать подобных ситуаций, будут рассматриваться в главе 4.

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

Сильное зацепление

Хотелось бы, чтобы связанное поведение находилось в одном месте, а несвязанное родственное поведение — где-нибудь в другом. Почему? Да потому, что при желании изменить поведение нам хотелось бы иметь возможность произвести все изменения в одном месте и как можно быстрее выпустить их. Если же придется изменять данное поведение во многих разных местах, то для выпуска изменения нужно будет выпускать множество различных служб (вероятнее всего, одновременно). Изменения во многих разных местах выполняются медленнее, а одновременное развертывание множества сервисов очень рискованно, и оба этих обстоятельства нам нужно как-то обойти.

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

Ограниченный контекст

В книге Эрика Эванса (Eric Evans) Domain-Driven Design (Addison-Wesley) основное внимание уделялось способам создания систем, моделирующих реально существующие области. В книге множество великолепных идей вроде использования единого языка, хранилища абстракций и т. п., а еще там представлено одно очень важное понятие, которое я поначалу упустил из виду: ограниченный контекст (bounded context). Суть его в том, что каждая отдельно взятая область состоит из нескольких ограниченных контекстов и то, что в каждом из них находится, — это предметы (Эрик широко использует слово «модель», что, наверное, лучше предмета), которые не должны общаться с внешним миром, а также предметами, которые во внешнем мире используются совместно с другими ограниченными контекстами. У каждого ограниченного контекста имеется четко определенный интерфейс, где он решает, какие модели использовать совместно с другими контекстами.

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

Ненадолго вернемся к бизнесу MusicCorp. Нашей областью будет весь бизнес, в пределах которого мы действуем. Он охватывает все: от товарного склада до реги­стратуры и от финансов до заказов. Мы можем создавать или не создавать модели всего этого в наших программах, но это все равно будет нашей рабочей областью. Рассмотрим части этой области, похожие на ограниченные контексты, на которые ссылался Эванс. В MusicCorp центром активности является товарный склад, где управляют доставля­емыми заказами (и случайными возвратами), принимают новые запасы, разъезжают вилочные погрузчики и т. д. А в финансовом отделе, возможно, не так оживленно, но все же там происходят весьма важные внутриведомственные дела. Его работники занимаются начислением зарплаты, ведут счета компании и составляют важные отчеты. Множество отчетов. И у них, наверное, есть и другая интересная бумажная работа.

Общие и скрытые модели

Финансовый отдел и товарный склад MusicCorp можно рассматривать как два отдельных ограниченных контекста. У них обоих имеется вполне определенный интерфейс для связи с внешним миром (в понятиях отчетов об инвентаризации, квитанциях об оплате и т. д.) и существуют детали, о которых должны знать только они (например, вилочные погрузчики и калькуляторы).