На первый взгляд вопрос простой, но он поднимает важную тему.
Мастер не заставляет фолловера что-то делать, он просто говорит, что допустимо. Фолловер может выбрать одно из допустимых действий(или соответствующую структуру действия) или не делать ничего. Это два разных слоя: policy и execution.
По сути вопрос такой:
allowed = {A, B}
follower сделал C?
Что делать?
Простой вариант: когда сам мастер проверяет действия фолловера. Если он присылает что-то вне допустимой схемы, мастер может отказать, проигнорировать или зафиксировать инцидент. Пример с workflow-движком.
Сложный вариант: три автономных модуля (счета, платежи, лимиты). Появились новые правила, требующие согласования всех модулей. Здесь архитектура может быть сложней и пригодится policy-service или schema-registry, для хранения схем и проверки действия фолловеров и при нарушениях инициирующие инциденты или другие реакции системы.
В обоих случаях организация исполнения и контроль соблюдения правил остаются задачей архитектуры системы. SDAP и его расширение SVSD описывают допустимые действия, их версионирование и механизмы безопасного распространения.
Согласен, модульная архитектура и оркестрация это базовые принципы. Но SDAP решает другие фундаментальные задачи:
допустимость действий как неизменяемая функция
отделение политики от инфраструктуры
эволюция бизнес-правил без изменения зависимых сервисов
Это на другом уровне абстракции. И это не точка оркестрации и не стейт машина. Это модель представления правил допустимых действий, которую могут использовать оркестраторы, сервисы, frontend.
Конечно это не серебряная пуля, но полезно там, где важна предсказуемость и версионированность правил.
Например.
Сценарий 1.Три автономных модуля: счета, платежи и лимиты, каждый со своей БД, общаются через оркестратор. Прилетели новые БП (например, бонусные лимиты VIP-клиентов) требуют согласования состояния всех трех модулей.
Даже при идеальной топологии:
* правила приходится дублировать в оркестраторе и сервисах;
* любые изменения требуют правок и деплоя модулей.
С SDAP правила определяются как схемы действий, а модули просто интерпретируют эти схемы, не меняя код. Это позволяет создавать новые правила и эволюционировать существующие без изменения сервисов.
Сценарий 2. Workflow-движок рисует процессы. Сервисы Gateway, Process Engine и Frontend автономны и взаимодействуют через события или оркестратор. Частые изменения процессов требуют обновления кода всех сервисах, иначе они не смогут корректно интерпретировать новые шаги и условия, рендеринг.
SDAP позволяет создавать и управлять этапами и правилами бизнес-логики, обеспечивая динамическую эволюцию процессов и согласованность действий, полностью отделяя правила от инфраструктуры и сервисов. Сервисы просто интерпретируют схему, и новые правила становятся доступны автоматически без изменений кода.
В идеале схема и правила должны быть максимально простыми и лаконичными, но при этом достаточными для корректной интерпретации.
Да, размазывание логики по сервисам усложняет договоренности и поведение, и это большая боль, и проблема не только в реализации, но и в эксплуатации. Компании тратят огромные средства, чтобы ее решить. Я лично сталкивался с этим. Хорошо, когда об этом думают на старте проекта, но лучше поздно, чем никогда.
Операции и подправила могут быть разбросаны, но если БП сервисов опираются на основное и следуют допустимым действиям мастера, тогда сохраняется явная ответственность.
Information
Rating
1,283-rd
Date of birth
Registered
Activity
Specialization
Фулстек разработчик, Архитектор программного обеспечения
На первый взгляд вопрос простой, но он поднимает важную тему.
Мастер не заставляет фолловера что-то делать, он просто говорит, что допустимо. Фолловер может выбрать одно из допустимых действий(или соответствующую структуру действия) или не делать ничего. Это два разных слоя: policy и execution.
По сути вопрос такой:
Что делать?
Простой вариант: когда сам мастер проверяет действия фолловера. Если он присылает что-то вне допустимой схемы, мастер может отказать, проигнорировать или зафиксировать инцидент. Пример с workflow-движком.
Сложный вариант: три автономных модуля (счета, платежи, лимиты). Появились новые правила, требующие согласования всех модулей. Здесь архитектура может быть сложней и пригодится policy-service или schema-registry, для хранения схем и проверки действия фолловеров и при нарушениях инициирующие инциденты или другие реакции системы.
В обоих случаях организация исполнения и контроль соблюдения правил остаются задачей архитектуры системы. SDAP и его расширение SVSD описывают допустимые действия, их версионирование и механизмы безопасного распространения.
Согласен, модульная архитектура и оркестрация это базовые принципы. Но SDAP решает другие фундаментальные задачи:
допустимость действий как неизменяемая функция
отделение политики от инфраструктуры
эволюция бизнес-правил без изменения зависимых сервисов
Это на другом уровне абстракции. И это не точка оркестрации и не стейт машина. Это модель представления правил допустимых действий, которую могут использовать оркестраторы, сервисы, frontend.
Конечно это не серебряная пуля, но полезно там, где важна предсказуемость и версионированность правил.
Например.
Сценарий 1.Три автономных модуля: счета, платежи и лимиты, каждый со своей БД, общаются через оркестратор. Прилетели новые БП (например, бонусные лимиты VIP-клиентов) требуют согласования состояния всех трех модулей.
Даже при идеальной топологии:
* правила приходится дублировать в оркестраторе и сервисах;
* любые изменения требуют правок и деплоя модулей.
С SDAP правила определяются как схемы действий, а модули просто интерпретируют эти схемы, не меняя код. Это позволяет создавать новые правила и эволюционировать существующие без изменения сервисов.
Сценарий 2. Workflow-движок рисует процессы. Сервисы Gateway, Process Engine и Frontend автономны и взаимодействуют через события или оркестратор. Частые изменения процессов требуют обновления кода всех сервисах, иначе они не смогут корректно интерпретировать новые шаги и условия, рендеринг.
SDAP позволяет создавать и управлять этапами и правилами бизнес-логики, обеспечивая динамическую эволюцию процессов и согласованность действий, полностью отделяя правила от инфраструктуры и сервисов. Сервисы просто интерпретируют схему, и новые правила становятся доступны автоматически без изменений кода.
В идеале схема и правила должны быть максимально простыми и лаконичными, но при этом достаточными для корректной интерпретации.
Да, размазывание логики по сервисам усложняет договоренности и поведение, и это большая боль, и проблема не только в реализации, но и в эксплуатации. Компании тратят огромные средства, чтобы ее решить. Я лично сталкивался с этим. Хорошо, когда об этом думают на старте проекта, но лучше поздно, чем никогда.
Операции и подправила могут быть разбросаны, но если БП сервисов опираются на основное и следуют допустимым действиям мастера, тогда сохраняется явная ответственность.