Общая модель, определенная и используемая различными микросервисами

Question

У нас есть сценарий, в котором мы отслеживаем машины, так называемые конечные точки. Мы получаем данные о событиях, происходящих на машине в Кафке, через какой-то механизм.Два разных микросервиса слушают тему для обработки данных.Обе службы имеют различное назначение

1. Оповещение : для создания оповещений на основе данных в теме.
2. Актив : Отображение события машиныДанные, поступающие в тему нашим клиентам.

Проблема, которую я вижу, состоит в том, что мы определили общую модель для следующих случаев в качестве библиотеки:

• Для сериализации данных на машинах, которые должны быть отправлены в kafka для используемых служб.
• Для десериализации данных, используемых двумя упомянутыми выше службами (Alerting и Asset)

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

• Оповещение (Ограниченный контекст): генерировать оповещения на основе данных. (Возможности для бизнеса или субдомена)
• Актив (Ограниченный контекст): Отображение данных машинного события клиентам (другой поддомен)

Также общая модель в виде библиотеки нарушает следующие требования:

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

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

Необходимо понять, какой правильный подход для микросервисов.

Answer 1

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

В некоторых случаях у вас может даже быть Shared Kernel, который является именно этим.

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

Таким же образом я могу использовать какой-то пакет Nuget, который обновляется до критической основной версии, что приводит к обновлению до этой версии, требующейперераспределение моей конечной точки.Хотя в этом случае это, вероятно, будет фактической конечной точкой и не будет напрямую связано с моделью домена ограниченного контекста.