Итак, если границы нашего сервиса вписываются в ограниченный контекст в нашей области и наши микросервисы представляют собой подобные ограниченные контексты, значит, мы взяли хороший старт в обеспечении слабой связанности и сильного зацепления микросервисов.
В ThoughtWorks мы сами столкнулись с проблемами слишком быстрого разбиения на микросервисы. Помимо консалтинга, мы также создали несколько продуктов. Одним из них был SnapCI — работающий на хост-машине инструментарий непрерывной интеграции и непрерывной доставки (эти понятия будут рассматриваться в главе 6). Ранее команда работала над другим подобным продуктом, Go-CD — инструментом доставки с открытым исходным кодом, который может развертываться локально, а не размещаться в облаке.
Хотя на самой ранней стадии в проектах SnapCI и Go-CD существовал повторно используемый код, в конечном итоге SnapCI оказался обладателем совершенно нового кода. Тем не менее предыдущий опыт команды в области разработки инструментария по доставке компакт-дисков стимулировал разработчиков к более быстрому определению границ и построению создаваемой системы в виде набора микросервисов.
Через несколько месяцев стало понятно, что сценарий использования SnapCI имел достаточно отличий, чтобы признать изначально определенные границы сервисов не совсем правильными. Это повлекло за собой внесение в сервисы множества изменений и связанные с этим большие затраты. В итоге команда опять объединила сервисы в единую монолитную систему, чтобы лучше понять, где должны пролегать границы. Год спустя команда смогла разбить монолитную систему на микросервисы, границы которых оказались гораздо более стабильными. И это далеко не единственный известный мне пример подобной ситуации. Преждевременная декомпозиция системы на микросервисы может обойтись весьма дорого, особенно если область вам плохо известна. Во многих отношениях куда проще иметь весь исходный код, требующий декомпозиции и разбиения на микросервисы, чем пытаться создавать микросервисы с самого начала.
Приступая к обдумыванию ограниченных контекстов, имеющихся в вашей организации, нужно размышлять не в понятиях совместно используемых данных, а в понятиях возможностей, предоставляемых такими контекстами всей остальной области. Товарный склад, к примеру, может предоставить возможность получения текущего списка запасов, а финансовый контекст — выдать состояние счетов на конец месяца или позволить внести новичка в платежную ведомость. Для этих возможностей может понадобиться взаимный обмен информацией, то есть совместно используемые модели, но мне довольно часто приходилось наблюдать, что обдумывание данных приводило к созданию безжизненных, основанных на CRUD (create — «создание», read — «чтение», update — «обновление», delete — «удаление») сервисов. Поэтому сначала нужно задать себе вопрос «Чем этот контекст занимается?», а затем уже вопрос «А какие данные ему для этого нужны?».
При проведении моделирования в виде сервисов эти возможности становятся ключевыми операциями, которые могут быть показаны по сети другим участникам системы.
В самом начале вы, наверное, определите ряд приблизительных ограниченных контекстов. Но они, в свою очередь, могут содержать следующие ограниченные контексты. Например, можно разбить товарный склад по признакам возможностей, связанных с выполнением заказа, управлением запасами или получением товаров. Рассуждая о границах своих микросервисов, сначала нужно оперировать понятиями наиболее крупных, приблизительных ограниченных контекстов, а затем, выискивая преимущества разбиения в пределах этих границ, приступать к дальнейшему дроблению на вложенные контексты.
Для пущего эффекта я видел эти вложенные контексты скрытыми ото всех остальных сотрудничающих микросервисов. Для внешнего мира они по-прежнему используются с целью реализации бизнес-возможностей на товарном складе, но при этом не знают, что, как показано на рис. 3.2, их запросы фактически открыто отображаются на два и более отдельных сервиса. Временами, как показано на рис. 3.3, можно прийти к решению, что для ограниченного контекста более высокого уровня больше смысла в том, чтобы не быть промоделированным в качестве границы сервиса, и вместо единой границы товарного склада можно выделить запасы, выполнение заказов и получение товаров.