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

Но есть более фундаментальный вопрос - кто в системе определяет правила игры?

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

• часть проверок живeт во фронтенде

• часть - в API

• часть - в промежуточных сервисах

• часть - во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

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

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

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

Для финтеха это особенно критично. Допустимость действия - это не просто проверка прав. Это функция состояния процесса, версии правил, контекста операции и регуляторных ограничений. Если эта допустимость зависит от связности сервисов или порядка их вызова, система становится хрупкой и уязвимой, и тогда начинается разговор о подходе, в котором бизнес-логика централизуется, версионируется и становится инвариантной к физической архитектуре.

Если допустимость действия зависит от нескольких сервисов, то ни один из них не является владельцем правил. UI может считать действие допустимым. Gateway - допустимым. Но один из downstream-сервисов внезапно его запретит.

Что это значит? О чем говорит?

Это признак того, что источник истины размыт. Поведение системы становится недетерминированным, почти магическим.

А что если у нас проверки распределены по сервисам? Тогда они выполняются в разные моменты времени.

И с чем же мы можем столкнуться? Просто однажды, действие, которое формально прошло все проверки, фактически станет недопустимым. Начинаются ретраи, компенсации, дополнительные блокировки и тп.

То есть, мы сталкиваемся с тем, что архитектура начинает влиять на бизнес-решения!

Но самое опасное происходит позже. Команда начинает принимать недальновидные решения, потому что иначе сломается процесс. Мы плодим костыли!

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

Архитектурная позиция, которую я предлагаю, звучит просто - Допустимость действия должна вычисляться в одном месте, на основе формализованной схемы процесса, и быть независимой от того, как физически организована система. Именно отсюда возникает подход SDAP.

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

Что означает централизованная допустимость на практике?

Это означает, что для каждого процессного контекста должен существовать единственный логический источник правил допустимости действий. Назовем его Master.

Master не обязан быть физически единым сервисом. Он может быть логическим компонентом, отдельным bounded context, или реализован через event-sourced агрегат. Ключевое требование - единственность источника допустимости.

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

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

Master знает:

• текущее состояние процесса

• версию правил

• список допустимых действий в этом состоянии

• контракты для этих действий

Master не выполняет бизнес-операции сам. Он определяет, можно ли их выполнять и в каком виде. Все остальные сервисы становятся исполнителями (followers).

Followers получают:

• разрешенное действие

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

Таким образом, проверка допустимости не размазывается, правила не дублируются.

Схема как источник истины

Ключевой элемент - это формализованная схема процесса.

• Не код в сервисах.

• Не условия в контроллерах.

• Не скрытые проверки в базе.

Явная схема, которая описывает состояния и допустимые переходы. Она версионируется. Она неизменяема для уже запущенных процессов. Каждый новый экземпляр процесса жестко связан с конкретной версией схемы.

Это дает:

• воспроизводимость поведения

• аудит

• возможность доказать, почему в 14:00 действие было доступно, а в 14:01 - нет

Самый важный эффект - это независимость бизнес-допустимости от физической топологии сервисов.

Между Master и исполнителями может быть - один сервис, пять сервисов, оркестратор, шина, асинхронная очередь, но это не влияет на допустимость, потому что допустимость уже вычислена.

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

Мы вновь делаем архитектуру инструментом, а не ограничением.

Рассмотрим примеры:

1. Архитектура приложения для динамического UI на основе SDAP

Пример описывает процесс, в котором бизнес-допустимые действия централизуются через Master (Workflow), а пользовательский интерфейс строится динамически.

Пояснение:

• Master (Workflow) - источник истины для бизнес-допустимости действий. Генерирует SDAP-схему, фиксирует переходы состояния процесса, хранит версию правил и текущие действия. В случае сбоя Process Engine или повреждения Processing DB, Master содержит достаточно информации для восстановления состояния Process Engine.

• Process Engine (Follower2) - интерпретирует SDAP-схему и применяет технические ограничения (права пользователя, роли, каналы доступа), не изменяя бизнес-допустимость и предоставляет разрешенные действия на основе SDAP-схем. Хранит версии схем, schemaHash, промежуточные статусы процессов и данные для Front. В случае сбоя Master или повреждения Business DB, Process Engine содержит достаточно информации для восстановления состояния Master. В рамках системы Process Engine не является частью Master и не управляет бизнес-правилами, он выполняет свои небизнесовые процессные функции, например авторизацию, интеграции с внешними системами и обработку промежуточных состояний процесса.

• Front (Follower1) - строит UI и собирает пользовательские артефакты, получая разрешённые действия от Process Engine на основе SDAP-схем. Не решает бизнес-допустимость, но обеспечивает корректное исполнение действий пользователя.

Ключевой эффект: любое изменение или дополнение процессов и правил на стороне Master не влияет на поведение и доступные действия у followers и, следовательно, не требует изменений их реализации.

Пример SDAP-схемы процесса:

{
  "processInstanceId": "12345",
  "processVersion": "v2",
  "schemaHash": "abcd1234",
  "actions": {
    "approve": { "type": "Boolean", "required": true, "label": "Согласовать" },
    "reject": {
      "type": "Boolean",
      "required": true,
      "label": "Отказать",
      "rules": {
        "master": { "detailsTask": { "type": "String", "required": true, "label": "Комментарий" } },
        "follower": { "uploadFile": true }
      }
    }
  }
}

2. Распространение действий между сервисами

Пример описывает процесс подтверждения платежа и отправки уведомления, в котором бизнес-допустимые действия централизуются Master, а остальные сервисы выполняют контрактные операции.

Пояснение:

Существует два вида услуг:

• Выставление счетов- подтверждение платежей

• Уведомитель - отправляет уведомления.

{
  "context": {
    "state": "payment_confirmed",
    "version": "2.0"
  },
  "data": {
    "amount": 150000,
    "user_id": "u_99"
  },
  "action_propagation": {
    "execute_notification": {
      "type": "external_call",
      "target": "http://telephony-service/make-call",
      "payload": {
        "to": "{{manager_phone}}",
        "script": "High value payment received: 150000"
      }
    }
  }
}

При изменении бизнес-правил (например, изменении порогового значения или введении нового канала) возникает необходимость:

• изменить код уведомления

• ввести дополнительную логику ветвления

• развернуть новую версию

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

1. Система Выставление счетов выступает в роли Master.

2. Уведомитель выступает в роли Follower.

3. Допустимые действия рассчитываются исключительно Мастером.

Master:

• описывает семантику действия, а конкретная инфраструктурная реализация остается на стороне Follower.

Follower:

• не анализирует сумму

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

• не определяет, какой канал уведомлений использовать

• не содержит деловых условий

Он:

1. Получает сообщение

2. Интерпретирует action_propagation

3. Выполняет описанное действие

Master проверяет результат Follower на соответствие контракту SDAP-схемы.

1. При расхождении фиксирует инцидент и при необходимости инициирует компенсацию или отклоняет переход состояния

2. В случае корректного выполнения - фиксирует переход состояния и версионирует процесс

Что это меняет системно?

• Логика допустимости становится детерминированной и воспроизводимой. Решение принимается один раз, в одном месте.

• Проверка допустимости и фиксация перехода состояния выполняются внутри Master как часть единой модели процесса.

• Версионирование становится естественным. Новая версия процесса - новая схема. Старые экземпляры продолжают жить по старым правилам.

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

Когда SDAP не нужен

• система представляет собой простой CRUD без процессных состояний

• допустимость действий не зависит от сложного жизненного цикла

• ошибка в разрешении действия не несет финансовых или регуляторных рисков

• команда не готова формализовывать и версионировать процесс

• бизнес-логика по сути уже централизована и не размазана по сервисам

Что SDAP не решает

• не гарантирует успешное исполнение действия

• не устраняет проблемы сетевых сбоев

• не заменяет компенсационные механизмы

• не отменяет необходимость идемпотентности

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

Подробнее о подходе можно узнать здесь