Извлечение бизнес-возможностей в сервисы¶

Для извлечения функций в сервисы необходимо брать вертикальный срез монолита, который состоит из:

входящих адаптеров, реализующих конечные точки API;
доменной логики;
исходящих адаптеров, таких как логика доступа к БД;
схемы базы данных монолита.

Вышеуказанный код извлекается из монолита и помещается в отдельный сервис.

Для извлечения сервиса может понадобиться разорвать зависимости и, возможно, разделить существующие классы, а также модифицировать структуру БД.
Извлечение сервисов обычно занимает много времени, в связи с чем следует тщательно подумать, какие сервисы нужно извлечь. Необходимо сосредоточиться на тех частях, которые приносят наибольшую пользу. Например, имеет смысл извлечь сервис, функции которого постоянно эволюционируют и имеют критическое значение с точки зрения бизнеса.

Разделение доменной модели¶

Чтобы извлечь сервис, необходимо вычленить его доменную модель из доменной модели монолита. Одна из проблем здесь состоит в устранении объектных ссылок, которые могу выйти за границы сервиса.

Эту проблему можно рассматривать с точки зрения агрегатов из DDD. Агрегаты будут ссылаться друг на друга при помощи первичных ключей, а не объектных ссылок.
Одна из проблем тут в том, что замена ссылок на первичные ключи может серьезно повлиять на клиентов, которые до сих пор работают со ссылками.
Также проблемным аспектом будет вычленение функциональности из класса, у которого есть другие обязанности. Обычно такая ситуация возникает с божественными классами¹, которым делегирована слишком большая ответственность.

Рефакторинг базы данных¶

Многие классы хранят свои данные на постоянной основе. Следовательно, вместе с сервисом из монолита извлекаются и данные. Кроме того, при разделении сущности нужно разделить соответствующую таблицу в БД и переместить ее часть в сервис.
При рефакторинге БД могут помочь рецепты из книги “Рефакторинг баз данных”²

Репликация данных для минимизации изменений¶

Предлагаемое решение состоит в том, чтобы оставить нужные поля в старой БД, но наполнять их при помощи триггеров, копируя их из БД сервиса.

Какие сервисы и в какой момент нужно извлекать¶

Следует тщательно продумать последовательность извлечения сервисов. Приоритет следует отдавать сервисам, приносящим наибольшую выгоду.
Переход стоит начать с проектирования. На протяжении короткого времени необходимо направить усилия на создание идеальной архитектуры и определение набора сервисов. Однако следует помнить, что по мере разбиения монолита и приобретения опыта есть смысл пересматривать архитектуру.
Есть несколько стратегий, с помощью которых можно определить последовательность извлечения сервисов.
Первая стратегия состоит в фактической заморозке работы над монолитом и извлечении сервисов по мере необходимости. Вместо того, чтобы реализовывать возможности или исправлять ошибки в монолите, извлекается нужный сервис или сервисы, и изменения делаются в извлеченном коде. Преимущество этого подхода в том, что он заставляет разбивать монолит. Недостаток - мотивацией для извлечения сервисов служат краткосрочные требования, а не долгосрочные потребности. В итоге можно потратить много усилий с минимальной отдачей.
Альтернативная стратегия больше заботится о планировании: модулям приложения назначается рейтинг в соответствии с тем, какую пользу ожидается получить от их извлечения. Есть три причины, почему извлечение может быть полезным:

Ускорение разработки. Если согласно плану какая-то часть приложения будет активно развиваться на протяжении следующего года, разработку можно ускорить путем извлечения в сервис.
Решение проблем с производительностью, масштабируемостью и надежностью.
Возможность извлечь другие сервисы. Иногда из-за зависимостей между модулями извлечение одного сервиса упрощает извлечение другого.

Последнее обновление : 2 декабря 2023 г.
Дата создания : 4 августа 2022 г.