State-first архитектура: поиск другого способа управления бизнес-логикой

[nin-jin]

У меня есть готовое решение и статья без нейрослопа: https://crus.hyoo.ru/#!=rnxlfb_4o4u02

[Akon32]

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

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

Что означает второе предложение?

Капитан-очевидность

А тут LLM использует мемы, которых пока не понимает.

[Snaret]

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

Оркестратор управляет процессами, сделай A → потом B → если не получилось — компенсируй C, а моя идея управляет состоянием данных.

Идеи схожи, но отличие именно в модели мышления process-first и state-first

[Akon32]

process-first и state-first

Странно, не встречал этих определений ранее, и гугл ничего не находит. ChatGPT объяснил, сославшись, однако, что это "внутренний жаргон" для терминов "workflow" и "state machine".

Но всё равно я не вижу разницы. Информационная система всё равно хранит и изменяет состояние, а делают изменения процессы. Если нужна согласованность данных, в любом случае будут правила, не допускающие повторных изменений и повторяющие попытки изменений, если они почему-то не произошли. Т.е. любой оркестратор, если он поддерживает согласованность данных, будет делать то, что вы описываете. И даже без оркестратора (стиль "хореография") будет то же самое, только логика размазана по сервисам.

[Snaret]

Информационная система всё равно хранит и изменяет состояние, а делают изменения процессы.

Все верно. И в этом проблема, процессы построены на связи микросервисов через средства (Rest, gRPC и тд), которые в свою очередь ломаются и не доходят. Бизнес-логика начинает зависеть от того, как именно мы связали сервисы. Я хочу от этого уйти.

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

И тут все верно, но в микросервисном мире эти правила размазаны между ними. То есть в одном сервисе 1я часть правил, во 2м вторая и так далее. В итоге согласованность - это не свойство модели, а эффект взаимодействия нескольких компонентов. Хотелось бы собрать эту логику в одном месте и сделать её атомарной и транзакционной.

Т.е. любой оркестратор, если он поддерживает согласованность данных, будет делать то, что вы описываете. И даже без оркестратора (стиль "хореография") будет то же самое, только логика размазана по сервисам.

В классическом оркестраторе согласованность данных является следствием корректно выполненного процесса: если все шаги A - B - C отработали, то состояние считается валидным. Если что-то не дошло — добавляются ретраи, компенсации и т.д. Я сознательно хочу перевернуть приоритеты. Первично не "какие шаги нужно выполнить2, а "какие инварианты состояния должны быть истинны после любого события".
Процессов как таковых Engine не знает - он лишь применяет правила, пока состояние не станет согласованным, либо откатывается.

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

[AlexViolin]

В качестве Engine логично использовать корень агрегата. Как отдельный объект это будет чрезмерное усложнение кода. Сама идея достаточно интересная.