При беглом изучении кода монолита может показаться, что код аккуратно разделён по бизнес-контекстам[81] и в нём не нарушается принцип единственности ответственности. Если это так, значит, можно взять код монолита, распределить этот код по микросервисам, соединить микросервисы между собой, и получится та же система, но на микросервисной архитектуре (рис. 48).

Рис. 48. Идеальное разделение кода монолита на микросервисы

Практика показывает, что границы ответственности так или иначе растекаются внутри монолита. Из-за этого не получается использовать «копипаст» из монолита для заполнения микросервиса кодом. Весь код и тесты придётся написать с нуля для правильного разделения ответственностей по микросервисам (рис. 49).

Рис. 49. Реальная ситуация с выделением кода из монолита в микросервисы

Если случилось чудо и код монолита окажется идеально написан (чего никогда не происходит), то всё равно этот код придётся дописывать и переписывать под требования микросервисной архитектуры и под изменения в инфраструктуре (см. п. 4).

Не поддавайтесь на оптимизм Владельца Продукта и разработчиков монолита. Закладывайте столько времени своих разработчиков и тестировщиков, как если бы вы писали систему с нуля, а не просто переносили готовый код из одного места в другое. Кроме этого, до начала работ желательно договориться с командой, писавшей монолит, чтобы они выделили время на ваши вопросы по коду.