Домены и команды

5 мин чтения

Shared Kernel: когда двум командам выгоднее разделить часть модели, чем дублировать её

Полная независимость доменов звучит красиво, но иногда две команды действительно должны одинаково понимать небольшой кусок модели. Shared Kernel позволяет разделить его сознательно — вместе с ценой совместного владения.

Какую проблему мы решаем

Иногда два bounded context должны использовать одинаковые определения или правила. Если каждый создаёт собственную копию, со временем они расходятся и бизнес получает две версии одной и той же истины.

Обратная крайность — вынести всё общее в гигантскую библиотеку и заставить команды менять её совместно. Тогда независимость исчезает.

Как работает Shared Kernel

Shared Kernel — это небольшой, осознанно общий фрагмент модели или кода, которым несколько контекстов владеют совместно. Изменения в нём требуют договорённости, потому что затрагивают всех участников.

Ключевое слово здесь — небольшой. Shared Kernel не должен становиться контейнером для всего, что когда-то показалось похожим.

Что получает бизнес

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

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

Что получает команда

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

Но команда теряет часть автономии: Shared Kernel нельзя менять так же свободно, как внутренний код собственного контекста.

Что получает клиент

Клиент получает более согласованное поведение разных частей продукта там, где бизнес ожидает одинаковых правил и терминов.

Чем мы за это платим

Главная цена — координация. Совместное владение означает совместные релизы, обсуждения совместимости и ответственность нескольких команд.

Если Shared Kernel растёт, он постепенно превращается в скрытый монолит внутри распределённой архитектуры. Тогда любое изменение снова начинает требовать участия всех.

Когда не нужно усложнять

Если две модели лишь похожи, но имеют разный бизнес-смысл, лучше не объединять их. Дублирование иногда дешевле постоянной связанности.

Shared Kernel оправдан, когда общий смысл действительно один, а цена расхождения выше цены координации.

Что стоит спросить перед решением

В итоге

Shared Kernel — не способ убрать дублирование любой ценой. Это сознательная покупка согласованности ценой части автономии.

Для бизнеса Shared Kernel полезен только там, где совместная модель стоит дешевле, чем две независимые версии одной важной истины.