Low-code как основа современной разработки: платформы Digital Q для проектирования бизнес-приложений

Когда компании переходят на микросервисную архитектуру, скорость разработки почти всегда замедляется — такова реальность. Больше синхронизации, больше согласований, больше кода и больше точек, где можно ошибиться. И в какой-то момент становится очевидно: чтобы строить цифровые продукты быстрее, нужно менять подход.

Сегодня бизнесу уже недостаточно просто автоматизировать процессы — важно делать это быстро. Настолько быстро, чтобы новые сервисы появлялись не через месяцы, а буквально за несколько дней. Именно поэтому low-code платформы начали играть ключевую роль в корпоративной разработке. На примере экосистемы Digital Q хорошо видно, как без лишнего кода можно собрать микросервис, спроектировать процесс и создать удобный интерфейс.

В этой статье разберем, как устроена архитектура экосистемы Digital Q, почему концепция PBC стала ключевой в современном IT, а также шаг за шагом проследим реальный сквозной процесс — от обработки данных и проектирования логики до создания финального пользовательского экрана.

Что такое PBC и зачем он нужен: новый взгляд на бизнес-функции

Термин PBC (Packaged Business Capabilities) появился в исследованиях Gartner и достаточно быстро стал стандартом в архитектурном подходе компаний, которые стремятся строить гибкие решения. 

PBC — это готовые бизнес-возможности, упакованные в виде программных компонентов. 

Такой своеобразный набор «кирпичиков», из которых можно собрать полноценное приложение.

В отличие от обычной микросервисной архитектуры, где каждая новая задача грозит открыть еще один сервис, PBC работает как стандартизированная «коробка», в которой уже есть:

• схемы данных,
• набор сервисов,
• API и события,
• логические модели,
• настройки поведения компонента.

То есть все то, что в классической разработке создается вручную, часто неоднородно, долго и с риском человеческих ошибок.

Главная особенность PBC — его узнаваемость бизнесом. Он выглядит не как набор таблиц, а как понятная сущность: «заявка на отпуск», «кредитный продукт», «профиль клиента», «договор» — каждый из этих элементов и есть отдельная бизнес-возможность. Один компонент решает одну конкретную задачу, и это делает систему понятней и более гибкой. 

Почему PBC тесно связаны с микросервисами

Несколько лет назад многие компании, включая «Диасофт», активно переходили на микросервисную архитектуру. Это была прогрессивная идея, но на практике всплыла серьезная проблема:

разработка микросервиса занимала минимум месяц, требовала большого числа участников, множества согласований, а значит — была дорогой и долгой.

Для MVP это долго, для бизнеса — дорого.

Особенно это било по MVP: идеи появлялись быстро, а реализовать их оперативно было почти невозможно.

Постепенно возникла потребность в экосистеме, которая позволила бы создавать сервисы быстрее и при этом не нарушать архитектурные принципы. Так появилась Digital Q — экосистема платформ, с помощью которых микросервисы, процессы и интерфейсы формируются на базе единых моделей и артефактов, а не вручную «с нуля».

Платформы экосистемы Digital Q

Экосистема Digital Q строится на трех ключевых платформах, каждая из которых отвечает за свой этап создания цифрового решения — от данных и логики до готового интерфейса.

Digital Q.Archer — конструктор PBC и микросервисов

Digital Q.Archer — это инструмент, в котором проектируются PBC, формируется структура данных, описываются API, события, логические схемы. Можно сказать, что именно Digital Q.Archer привел к новой скорости разработки.

Платформа состоит из двух ключевых компоненты.

Дизайнер PBC

В нем аналитик проектирует:

• бизнес-объекты,
• связи между ними,
• атрибуты,
• API,
• события.

Главная ценность — визуальная логическая схема. Это не просто диаграмма, а полноценный инструмент моделирования. Никакой ручной верстки схем: объекты просто перетягиваются на холст, связываются, дополняются атрибутами. Здесь же работает автоматическая валидация: если в структуре есть ошибки или нарушения, система сразу подсветит проблему.

Также полезна автогенерация английских названий атрибутов — банальная, но экономящая время функция, особенно когда проектируются сложные PBC.

Дизайнер микросервиса

После публикации PBC Digital Q.Archer автоматически собирает микросервис:

• формирует репозиторий,
• генерирует CRUD-операции,
• собирает CI/CD-пайплайн,
• прокладывает контракт для API.

Архитектор или разработчик при необходимости может уточнить технические параметры — выбрать тип базы данных, настроить обмен сообщениями, определить особенности хранения. Но основная структура к этому моменту уже сформирована автоматически, и именно это заметно сокращает время до получения готового результата.

Digital Q.BPM — сердце сквозного процесса

Если Digital Q.Archer отвечает за данные и логику, то Digital Q.BPM — за процесс. Это движок проектирования и исполнения бизнес-процессов. Он использует:

• нотацию BPMN 2.0 для описания процессов,
• нотацию DMN для бизнес-правил,
• JSON-схемы для структур данных.

Платформа умеет взаимодействовать как с актуальными, так и с устаревшими протоколами — от REST и Kafka до SOAP. В случаях, когда процесс включает несколько связанных действий, предусмотрены механизмы компенсации, позволяющие корректно отменить цепочку операций. Благодаря встроенному управлению версиями любые изменения или пробные настройки процессов проходят безболезненно и остаются под контролем.

Digital Q.BPM состоит из четырех компонентов.

Дизайнер процессов

Дизайнер бизнес-процессов в Digital Q.BPM — это центральный инструмент для создания приложений на базе процессов. Он объединяет:

• реестр процессов и правил, 
• удобную навигацию,
• визуальный редактор.

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

В редакторе используется BPMN 2.0: есть рабочая область, палитра элементов и панель свойств. Дизайнер поддерживает интеграции через REST и SOAP, работу с Kafka, вызовы методов и делегатов, назначение пользовательских задач, ветвления и параллельные сценарии. 

Это не no-code, а low-code: основная структура — визуальная, но в местах, где нужна логика, можно вставить JavaScript или Groovy.

Диаграммы бизнес-правил могут быть встроены прямо в процесс, а при публикации все связанные артефакты разворачиваются вместе в составе микросервиса.

Сервис исполнения

После публикации диаграмма превращается в исполняемый код.

Появляется контроллер Swagger, с которым можно:

• запускать процесс,
• изменять его контекст,
• получать статус.

В основе лежит движок Camunda, а все остальное (интерфейсы, задачи, мониторинг, управление контекстом) разработано непосредственно на базе экосистемы Digital Q.

Управление пользовательскими задачами

Управление пользовательскими задачами – это компонент, где пользователь видит свои задачи, назначает исполнителей, ищет нужные элементы, фильтрует, настраивает отображение.

Функциональность компонента довольно широкая:

• собственные фильтры и сохраненные представления,
• разметка задач цветами и метками,
• таймеры и SLA,
• поиск по атрибутам,
• привязка кастомного виджета к задаче,
• выбор исполнителя по ролям и группам.

Отдельно стоит выделить шаблоны задач — это почти мини-настройка будущего поведения процесса:

• сроки исполнения,
• алгоритм распределения задачи,
• действия (подтвердить, отменить, редактировать),
• привязанный интерфейс (виджет),
• ответственные лица.

Мониторинг процессов

После запуска процесса за его выполнением можно наблюдать в режиме реального времени. Каждый процесс исполняется в своем микросервисе, но при этом мониторинг собирает все данные в единую консоль, где доступны:

• Общая статистика по выполнению процессов. Показывает завершенные, активные и “упавшие” процессы, а также самые долгие шаги.
• Режим Live с отображением актуальной активности. Позволяет отслеживать исполнение в реальном времени, просматривать диаграмму с подсветкой выполненных шагов, параметры процесса, последовательность действий и историю задач.
• Детализированный разбор инцидентов. Этот раздел показывает ошибки во всех сервисах, позволяет открыть проблемный процесс, увидеть на диаграмме точку сбоя, изучить параметры, бизнес-правила и последовательность шагов, что значительно ускоряет поиск причин и исправление логики.

Digital Q.Palette — визуальный дизайнер интерфейсов

Digital Q.Palette — это платформа для создания UI без необходимости вручную верстать на HTML/CSS.

Платформа работает на современном технологическом стеке в микросервисной архитектуре и предоставляет:

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

Преимущество Digital Q.Palette — автоматическая верстка по правилам UI/UX. Если сравнивать с Figma, то Digital Q.Palette  снимает 90% рутины: не нужно выравнивать кнопки, считать отступы, думать о гриде — система все делает сама.

Сквозной процесс: пример оформления отпуска

Чтобы показать, как работает Digital Q на практике, проще всего разобрать сквозной процесс оформления отпуска — от настройки данных до пользовательской формы и финального прохождения по процессу.

Подготовка PBC в Digital Q.Archer

В качестве основы берется PBC «Заявка на отпуск». Внутри него уже описана вся бизнес-логика, данные и структура объектов. Этот компонент включает в себя:

• бизнес-объекты,
• атрибуты (например, тип отпуска, даты, комментарий),
• логическую схему, справочники, события и API.

Если надо дополнить модель данными, на логической схеме добавляется новый атрибут, и после сохранения он сразу появляется в физической модели. Дальше остается задать ему корректное имя на латинице и опубликовать новую версию PBC. С этого момента платформа Digital Q.Archer делает все сама: запускает сборку, создает новую версию микросервиса и обновляет Swagger-контракты.

Проектирование бизнес-процесса в Digital Q.BPM

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

• пользовательская задача для создания заявки,
• интеграционный шаг, который передает данные в микросервис,
• задача согласования руководителя,
• получение списка заявок из внешней системы,
• финальная обработка.

Важно, что весь процесс общается с микросервисом через REST API, который автоматически создается на основе PBC.

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

Создание UI в Digital Q.Palette

Теперь пользователю нужно где-то создать заявку, и на этом этапе подключается Digital Q.Palette. Интерфейс здесь собирается визуально — без HTML, CSS и ручной верстки. Форма строится по шагам:

• создается страница,
• на ней размещается карточка — основной контейнер,
• добавляется заголовок,
• формируется сетка с колонками,
• вставляются нужные поля: автора, тип отпуска, даты начала и окончания, количество дней, комментарий,
• добавляются две кнопки — «Создать» и «Отмена».

Каждый элемент автоматически подстраивается под ширину, корректно ведет себя на мобильных устройствах и может менять стиль, если поменяется тема.

Для руководителя создается отдельная страница. В ней те же поля, только уже в режиме «только чтение», наряду с этим выводятся рассчитанные отпускные и указывается согласующий. Внизу — набор действий: подтвердить, отменить или отправить на доработку. 

Запуск сквозного процесса

Когда все части готовы, можно запускать процесс целиком. Пользователь открывает форму, заполняет заявку, а процесс сразу же создает запись в микросервисе и переходит к следующему шагу. В мониторинге видно, как он дошел до пользовательской задачи — руководитель получает ее у себя, открывает форму и выбирает нужное действие. Если заявка подтверждается, процесс идет дальше, выполняет интеграционный шаг, обновляет данные и завершает выполнение.

В мониторинге можно увидеть:

• весь путь исполнения процесса,
• длительность каждого шага,
• параметры всех интеграций,
• статистику и KPI,
• движение данных внутри процесса.

Внесение изменений «на горячую»

Если спустя время нужно добавить новый атрибут в заявку или поменять логику — в этом и есть сила платформ экосистемы Digital Q.  

Одна из ключевых ценностей low-code подхода — возможность быстро менять модель данных, бизнес-логику или UI без долгих циклов разработки.

Чтобы показать это на практике, внесем изменение в наш PBC и проведем его по всей цепочке. Допустим, надо добавить новый атрибут в PBC «Заявка на отпуск». Что происходит дальше?

• Публикуется новая версия PBC. После публикации Digital Q.Archer автоматически обновляет микросервис, формирует новую версию API, запускает pipeline сборки и обновляет Swagger-документацию.
• Обновляется процесс в Digital Q.BPM. Для включения нового поля в бизнес-логику достаточно открыть процесс, добавить параметр в маппинг или скрипт, опубликовать обновленную версию диаграммы.
• Обновляется пользовательский интерфейс в Digital Q.Palette. В дизайнере создается или добавляется новое поле на форму, после чего проект публикуется.

Никакого ручного переписывания кода, схем, интеграций или документации — все обновляется автоматически.

Цепочка изменений выглядит так:

PBC → Микросервис → Бизнес-процесс → Интерфейс

Таким образом, изменение в данных автоматически проходит через микросервис, процесс и UI, сохраняя целостность и работоспособность сквозного решения.

Итоги: зачем бизнесу нужен low-code

Экосистема Digital Q покрывает весь цикл разработки: от данных до UI, от логики до мониторинга. И что особенно важно — создает этот цикл быстро и безопасно.

• Разработка ускоряется в разы. То, что раньше занимало месяц, теперь можно собрать за несколько дней. И речь не о прототипе “на коленке”, а о реальном работающем сервисе — с микросервисом, процессом, UI и мониторингом.
• Стоимость MVP резко падает, так как на старте не нужна большая команда разработчиков. Первые версии функционала может собрать аналитик или продуктовый менеджер. Разработчик подключается только там, где нужна кастомная логика.
• Снижается количество ошибок. Автоматическая генерация микросервисов, валидация схем, проверка BPMN, единые контракты уменьшают риски.
• Бизнес становится самостоятельнее, появляется возможность быстро менять процессы, данные, формы без привлечения команды разработчиков.
• Ускоряется time-to-market. Digital Q позволяет проверять гипотезы чаще, дешевле и быстрее. Это критично для компаний, которые активно развивают цифровые продукты.

FAQ: как работает генерация микросервисов, версии PBC и архитектура Digital Q

Генерируется ли код микросервиса автоматически?

Да. Код микросервиса генерируется автоматически — Digital Q использует стандартный технологический стек. Основу составляет Java + Spring, поэтому все сервисы выходят единообразными, предсказуемыми и готовыми к CI/CD.

Внутри бизнес-процессов используются JavaScript и Groovy, а при необходимости можно подключить Python. В бизнес-правилах доступен расширенный набор языков — выбор зависит от конкретного сценария.

Можно ли генерировать бизнес-логику вместе с API?

CRUD-операции и типовой контракт создаются автоматически, но бизнес-методы не генерируются.

Если в PBC добавлен нетиповой API — Digital Q создает контракт и всю структуру, но логика реализации остается за разработчиком. Иначе говоря, платформа готовит «рамку», а наполнить ее смыслом — уже задача кода.

Доступна ли валидация для CRUD?

Да. Внутри PBC можно описать:

• обязательность атрибутов,
• тип данных,
• логические форматы.

Этого достаточно, чтобы типовые методы работали корректно, но сложная проверка правил — уже часть индивидуальной реализации.

Можно ли визуально задавать контекст процесса?

Контекст процесса задается через JSON-схему. Это полноценная структура: вложенные объекты, списки, обязательные поля. Схема редактируется через интерфейс Digital Q.BPM — не нужно писать XML или JSON руками.

Внутри самого процесса переменные обрабатываются через скрипты — стандартный подход для BPMN.

Важно: JSON-схема становится частью Swagger-контракта микросервиса, который запускает процесс.

Где исполняются процессы? Внутри одного кластера или в сервисах?

Процессы упаковываются в отдельные микросервисы. Каждый такой микросервис содержит:

• собственный рантайм Camunda,
• собственную базу,
• собственную версию процесса.

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

Можно ли визуально настраивать интеграцию через REST?

Сейчас маппинг задается вручную — через скрипты или свойства шага процесса. Но в бэклоге Digital Q.BPM есть задача — дать возможность выбирать API прямо из списка PBC и настраивать маппинг визуально. 

Это упростит работу аналитиков, которые не хотят писать код для каждой интеграции.

Как работают версии PBC и процессов?

Версионирование — одна из важных частей платформы.

• Новая версия PBC генерирует новую версию микросервиса.
• Новый процесс получает свой отдельный контроллер.
• Старые процессы продолжают работать на своих версиях — они не ломаются, пока не завершатся.

Если старая версия процесса использует старый формат данных, он будет обращаться к нужной версии микросервиса. То есть одновременно могут существовать несколько поколений логики — каждая безопасно работает со своей API-версией.

Что делать, если изменился атрибутивный состав?

Digital Q проверяет обратную совместимость.

Если изменение несовместимо — например, удален обязательный атрибут — публикация блокируется. Это защищает от случайных поломок.

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

Как избежать дублирования функционала при разработке?

Полностью автоматического поиска дублей нет, но дубли предотвращаются архитектурно.

В экосистеме Digital Q работает несколько уровней контроля:

• Институт главных архитекторов, где продукты распределены по бизнес-областям. Ответственный архитектор знает, какие компоненты уже существуют в домене.
• Сквозная документация, которая собирается из всех артефактов Digital Q, позволяет искать уже созданные объекты, PBC, процессы и API.
• Дизайн-спринты, которые проходят ДО начала разработки. На этом этапе согласуются логическая схема, объем функционала, архитектурные принципы, макеты интерфейсов. Если в логической схеме видно, что функционал пересекается, это обсуждается до начала реализации.
• Архитектурный надзор — более глубокий контроль в процессе разработки. Другими словами, дублирование предотвращается не одной кнопкой, а сочетанием процессов и архитектурной ответственности.

Как определяется итоговое количество микросервисов в PBC?

Количество микросервисов зависит от связей в логической схеме PBC.

Платформа использует принципы нотации ArchMate:

• связи агрегации позволяют объединить объекты в один микросервис,
• связи композиции заставляют разделять объекты по разным сервисам.

Платформа предлагает разбиение, но решение всегда остается за аналитиком или архитектором. Если модель данных выглядит неудачно или получается слишком много сервисов, корректируется схема — и генерация повторяется.