К книге
Антихрупкость в ITРаздел II. IT-архитектура для достижения бизнес-целей. Глава 4. Где и как применять low-code платформы. Когда применение low-code оправдано
72%
Раздел II. IT-архитектура для достижения бизнес-целей. Глава 4. Где и как применять low-code платформы. Когда применение low-code оправдано
108

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

Работающим подходом является комбинация 1) low-code платформы для визуализации процесса и 2) реализация всех функций этого процесса в виде обычного ПО. Мы применяем для этого BPMN-движки типа Camunda и микросервисную архитектуру. На BPMN описывается процесс, а микросервисы реализуют нужные функции, включая интеграцию, работу с нагрузками, автотесты (рис. 59).

Рис. 59. Разделение визуального описания системы и стандартного подхода с написанием кода

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

В комбинации low-code + обычное ПО тоже есть сложности. Если подойти к процессу без должного опыта и внимания, то можно создать неподдерживаемое месиво из квадратиков и стрелочек. Тут нужны профессионалы, которые отлично знают нотацию BPMN, хорошие аналитики, готовые разложить процесс на части и учесть все исключительные ситуации. Откуда тогда экономия?

Экономия времени и денег получается за счёт декларативного описания процесса:

1. Его видно, поэтому проще коммуницировать внутри команды и с пользователями.

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

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

4. BPMN – довольно популярная нотация, то есть знатоки есть среди разных профессией. При этом эта нотация всеобъемлюща, ею можно покрыть всё необходимое для работы.

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

Предыдущая главаГлава 108 из 149Следующая глава