Обычно у монолита есть одна или две большие базы данных, содержащие в себе разношёрстные мастер-данные. В самом монолите написан код, который управляет этими мастер-данными. Например, если «зелёная» часть базы данных – это адресный справочник, то «зелёный» код монолита управляет адресами. Получается, в базе данных монолита множество мастер-данных, а в коде монолита много мастер-систем (рис. 46).

Рис. 46. Связь приложения и базы данных в монолите

В микросервисах управление мастер-данным происходит иначе: баз данных много, перемешивать мастер-данные между микросервисами нельзя, а управлять мастер-данными может только один микросервис. Например, «зелёный» микросервис теперь получил свою базу данных с адресами и только он может вносить изменения в эти мастер-данные. Другие микросервисы могут читать данные с адресами, но только через «зелёный» микросервис (рис. 47).

Рис. 47. Каждый микросервис работает со своим хранилищем данных

Чёткое разграничение мастер-данных и мастер-систем по микросервисам нужно закладывать в оценку перехода. Занимает такая работа довольно много времени, которое уходит на следующее:

1. анализ схемы данных монолита,

2. анализ потоков обработки данных,

3. анализ использования данных сторонними системами,

4. бизнес-цели компании по работе с данными,

5. «нарезка» данных по новым базам,

6. миграция данных в новые базы микросервисов,

7. тестирование миграции.

Четыре основные стратегии работы с мастер-данными описаны в статье «Управления мастер-данными в микросервисной архитектуре»[80]. Желательно изучить эту тему до проектирования новой архитектуры.

Как и предыдущие факторы, переработку мастер-данных нужно оценивать и учитывать в бюджете перехода на микросервисы ещё до старта перехода.