НМЦК как шаг к тарифной и продуктовой декомпозиции

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

Вынос НМЦК в отдельный сервис был не про переход на микросервисы и не про инфраструктуру. Это был шаг в сторону продуктовой и тарифной декомпозиции системы.

От технического разбиения — к бизнес-доменам

Кросс-доменные сервисы решают инфраструктурные задачи и используются практически в любом сценарии.

С НМЦК ситуация иная: это конкретный бизнес-процесс, который нужен не всем клиентам и не во всех конфигурациях продукта.

Поэтому вопрос стоял так: держать НМЦК внутри общего контура или выделить его как отдельный поставляемый домен.

Мы выбрали второй вариант.

НМЦК как поставляемый бизнес-процесс

НМЦК в системе — это законченный процесс со своим жизненным циклом:

• формирование и редактирование заявки;
• выбор и обоснование метода расчёта;
• взаимодействие со страховыми компаниями;
• сбор, сравнение и фиксация предложений.

Этот процесс:

• имеет собственные роли;
• пересекается с другими доменами только через чёткие точки интеграции;
• может быть включён или исключён из поставки без влияния на остальной функционал.

С этой точки зрения НМЦК логичнее рассматривать как продуктовую единицу, а не как внутренний модуль.

Архитектура как отражение тарифной модели

Выделение НМЦК в отдельный сервис позволило сделать архитектуру напрямую связанной с тарифной логикой:

• клиент получает только те бизнес-процессы, которые ему нужны;
• лишний функционал может быть отключён без технических компромиссов;
• развитие домена не тянет за собой изменения в несвязанных частях системы.

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

Чёткие границы вместо универсальных модулей

В рамках сервиса НМЦК мы зафиксировали простой принцип: один сервис — один бизнес-домен.

Сервис отвечает только за заявки НМЦК и их жизненный цикл и не берёт на себя:

• хранение пользователей;
• общесистемные справочники;
• коммуникационные механики.

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

Что это дало на уровне продукта

С точки зрения продукта и разработки мы получили:

• возможность поставлять НМЦК как отдельный функциональный блок;
• основу для гибкой тарифной модели;
• снижение связности между доменами;
• более управляемое развитие сложных бизнес-процессов.

Это не «архитектурный эксперимент», а последовательный шаг в развитии платформы.

Вывод

Вынос НМЦК в отдельный сервис — это не про технологии и не про моду на микросервисы.

Это про осознанную декомпозицию продукта по бизнес-процессам, где архитектура напрямую поддерживает модель поставки и тарификации.

Следующие шаги в этом направлении будут решаться так же: через анализ домена, его самостоятельности и ценности для клиента, а не через желание «дробить систему».