Comments 8
Если допустимость действия зависит от нескольких сервисов, то ни один из них не является владельцем правил.
Дак микросервис это и есть сплошное размытие ответственности. За аутентификацию отвечают например 5 сервисов, за которые отвечают 10 программистов, получается что за аутентификацию конкретно никто не ответственен, каждый ответственный за 1 маленький кусочек
https://habr.com/ru/articles/992060/ - почитайте, есть схожесть идей
Да, размазывание логики по сервисам усложняет договоренности и поведение, и это большая боль, и проблема не только в реализации, но и в эксплуатации. Компании тратят огромные средства, чтобы ее решить. Я лично сталкивался с этим. Хорошо, когда об этом думают на старте проекта, но лучше поздно, чем никогда.
Уже который раз замечаю путаницу между логическими модулями и инфраструктурой, на которой осуществляется их хостинг.
Принципы построения гибкой и устойчивой архитектуры достаточно просты:
В системе должны быть выделены логические модули. Модуль это единый набор функциональности. Например, модуль управления профилем пользователя. Или модуль управления способами входа пользователя (mfa, sso, пароли). Модули между собой не общаются , друг от друга не зависят. У каждого модуля свое изолированное пространство БД.
В системе должны быть точки оркестрации: стейт машины, менеджеры процессов и тд. Они координируют модули между собой. Коммуникация с модулями только по логическому каналу.
Не важно, модули сейчас развернуты через монолит или микросервисы. Сервер базы данных один или у каждого модуля свой. Это детали и инфраструктуры. Логика не меняется никак от того, что инфраструктура какого-то из модулей изменилась (например, на него приходится повышенная нагрузка и его надо точечно масштабировать)
Достаточно по возможности придерживается этих принципов и проблем с размытостью бизнес логики не будет.
Согласен, модульная архитектура и оркестрация это базовые принципы. Но SDAP решает другие фундаментальные задачи:
допустимость действий как неизменяемая функция
отделение политики от инфраструктуры
эволюция бизнес-правил без изменения зависимых сервисов
Это на другом уровне абстракции. И это не точка оркестрации и не стейт машина. Это модель представления правил допустимых действий, которую могут использовать оркестраторы, сервисы, frontend.
Конечно это не серебряная пуля, но полезно там, где важна предсказуемость и версионированность правил.
Например.
Сценарий 1.Три автономных модуля: счета, платежи и лимиты, каждый со своей БД, общаются через оркестратор. Прилетели новые БП (например, бонусные лимиты VIP-клиентов) требуют согласования состояния всех трех модулей.
Даже при идеальной топологии:
* правила приходится дублировать в оркестраторе и сервисах;
* любые изменения требуют правок и деплоя модулей.
С SDAP правила определяются как схемы действий, а модули просто интерпретируют эти схемы, не меняя код. Это позволяет создавать новые правила и эволюционировать существующие без изменения сервисов.
Сценарий 2. Workflow-движок рисует процессы. Сервисы Gateway, Process Engine и Frontend автономны и взаимодействуют через события или оркестратор. Частые изменения процессов требуют обновления кода всех сервисах, иначе они не смогут корректно интерпретировать новые шаги и условия, рендеринг.
SDAP позволяет создавать и управлять этапами и правилами бизнес-логики, обеспечивая динамическую эволюцию процессов и согласованность действий, полностью отделяя правила от инфраструктуры и сервисов. Сервисы просто интерпретируют схему, и новые правила становятся доступны автоматически без изменений кода.
В идеале схема и правила должны быть максимально простыми и лаконичными, но при этом достаточными для корректной интерпретации.
Master сказал, а Follower не сделал. Кто виноват и что делать?
На первый взгляд вопрос простой, но он поднимает важную тему.
Мастер не заставляет фолловера что-то делать, он просто говорит, что допустимо. Фолловер может выбрать одно из допустимых действий(или соответствующую структуру действия) или не делать ничего. Это два разных слоя: policy и execution.
По сути вопрос такой:
allowed = {A, B}
follower сделал C?Что делать?
Простой вариант: когда сам мастер проверяет действия фолловера. Если он присылает что-то вне допустимой схемы, мастер может отказать, проигнорировать или зафиксировать инцидент. Пример с workflow-движком.
Сложный вариант: три автономных модуля (счета, платежи, лимиты). Появились новые правила, требующие согласования всех модулей. Здесь архитектура может быть сложней и пригодится policy-service или schema-registry, для хранения схем и проверки действия фолловеров и при нарушениях инициирующие инциденты или другие реакции системы.
В обоих случаях организация исполнения и контроль соблюдения правил остаются задачей архитектуры системы. SDAP и его расширение SVSD описывают допустимые действия, их версионирование и механизмы безопасного распространения.
Бизнес-логика первична, микросервисы — вторичны