Читать книгу Философия и цифровые технологии. Сборник статей - Александр Болдачев - Страница 38

Архитектуру EventFlow, по сути, следует рассматривать как событийный вариант шаблона DataFlow: соответствующие программы обычно представляются в виде направленного графа, в узлах которого расположены операторы, а ребра указывают на зависимости узлов по данным. Оператор очередного узла начинает выполняться сразу по получении всех необходимых данных от предшествующих узлов. Данные по ходу вычислений передаются от узла к узлу в виде токенов (рис. 1). Первые варианты DataFlow-компьютеров появились более полувека назад, но не получили широкого распространения из-за ряда нерешенных проблем, проявившихся как на уровне архитектуры, так и при создании языков программирования.

EventFlow наследует от DataFlow принцип асинхронной генерации новых данных по мере готовности результатов предшествующих операций, но в качестве данных выступают не числовые или строковые значения, а семантически определенные события: новое предметное событие генерируется по модельному событию при появлении всех обусловливающих событий (рис. 2). Иначе говоря, EventFlow-система ориентирована не на преобразование входных данных в выходные с передачей промежуточных результатов от оператора к оператору, а на реализацию бизнес-логики, которая прописана в семантических моделях. При этом генерируемые предметные события фиксируют в графе шаги выполнения алгоритма, а не промежуточные данные расчетов. Модели EventFlow – это программы на семантическом языке, исполняемые универсальным контроллером с использованием данных графа, а результатом исполнения моделей являются новые предметные события.

Важным отличием EventFlow является то, что модельные события, определяя семантику предметного события и условия его генерации, не содержат данных о последующих шагах бизнес-логики. То есть если узел графа DataFlow «знает», куда переслать токен с результатом вычислений, то модельные события в EventFlow задают только логическую обусловленность собственного выполнения, не предписывая условий для генерации последующих событий. Решение без токенов, с одной стороны, упрощает архитектуру, а с другой – соответствует бизнес-схеме, когда каждый актор выполняет свою операцию при получении всех необходимых для этого ресурсов и не осведомлен о том, кто воспользуется результатом его работы – ответственность за выполнение следующих шагов будет лежать уже на других акторах.

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

Особо следует обратить внимание на соотношение подхода EventFlow и технологии no-code. Модельные события движка EventFlow создаются с помощью экранных форм, и пользователям достаточно знать лишь основы событийной семантики (базовые примитивы и принципы построения исполняемых моделей действий) – им не требуется осваивать синтаксис языка описания событий и формат событий. По сути, EventFlow – это технология no-code, в которой исполняемым кодом являются событийные модели, то есть последовательности семантически определенных записей в темпоральном графе, а не скомпилированный программный код, который получается на выходе no-code-платформ. Конечно, EventFlow-движок написан на традиционном языке программирования и запускается на стандартном компьютере, но вся бизнес-логика реализуется на уровне семантически определенных событий.