Проектирование интеграционного слоя¶

Проектирование API интеграционного слоя¶

Проектирование интеграционного слоя нужно начинать с определения того, какие API он будет предоставлять доменной логике. Существует несколько стилей интерфейсов, их выбор зависит от того, запрашиваются данные или обновляются. Если данные запрашиваются, это API лучше инкапсулировать в виде интерфейса репозитория. Если обновляются — в виде интерфейса сервиса (service).

Выбор стиля взаимодействия и механизма IPC¶

Важное архитектурное решение — выбор стиля взаимодействия и механизмов IPC, которые позволят сервису и монолиту общаться. Как говорилось, в нашем распоряжении несколько таких стилей и механизмов. Варианты использования зависят от того, что именно требуется одной стороне для запрашивания или обновления данных другой.
Если одной стороне требуется запросить данные, есть такие варианты. Первый вариант состоит в том, чтобы адаптер, реализующий интерфейс репозитория, обращался к API провайдера данных. Обычно это взаимодействие вида “запрос-ответ”.
Важным преимуществом этого подхода будет его простота, а недостатком — потенциальная неэффективность. Также возможно снижение доступности вследствие синхронной природы такого взаимодействия.
Альтернативный подход состоит в том, чтобы потребитель хранил у себя реплику данных — в сущности, CQRS-представление. Для поддержания ее в актуальном состоянии потребитель данных подписывается на доменные события, публикуемые провайдером.

Реализация предохранительного слоя¶

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

Как монолит публикует и подписывается на события¶

Доменные события — важный механизм взаимодействия. Однако модификация монолита для публикации и потребления событий может стать непростой задачей.
Монолит может публиковать доменные события несколькими способами, например, используя тот же механизм, что и в сервисах. Для этого нужно найти все участки кода, где изменяется определенная сущность и вставить туда вызов API, публикующий события. Однако, модификация монолита может занять много времени и породить новые ошибки. Также бизнес-логика может содержать хранимые процедуры, из которых нельзя так просто опубликовать доменные события.
Другое решение — в публикации доменных событий на уровне БД. Для этого можно отслеживать изменения БД. Ключевым преимуществом будет отсутствие необходимости изменять монолит. Недостатком будет то, что бывает сложно определить причину изменения и сформировать высокоуровневое бизнес-событие, что приводит к тому, что в публикуемых событиях будут отражены скорее изменения таблиц, нежели бизнес-сущностей.
Подписка на события в этом смысле проще. Однако может случиться так, что монолит написан на языке, для которого нет клиента брокера сообщений. В этом случае нужно написать вспомогательное приложение, которое будет обновлять БД монолита напрямую.

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