Digital Q.Archer: как создавать бизнес-приложения нового поколения

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

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

Digital Q: экосистема цифровой трансформации

Digital Q - это экосистема low-code платформ, предназначенных для цифровой трансформации бизнеса. Она объединяет технологические, производственные, инфраструктурные и кросс-продуктовые решения.

«С помощью инструментов Digital Q мы проектируем и создаем мощные бизнес-функциональные блоки, состоящие из отдельных компонентов», – поясняет Дмитрий Старов, директор департамента «Инструменты и технологии разработки» компании «Диасофт».

Эти блоки в компании называют Package Business Capabilities (PBC) – «упакованные бизнес-возможности». Именно они стали ключевым строительным элементом архитектуры Digital Q.

Что такое PBC и почему это важно

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

Микросервис – это технический компонент, выполняющий одну изолированную задачу в коде. Но, как отмечают специалисты Gartner, бизнесу важнее понимать не логику кода, а то, какую бизнес-задачу решает тот или иной компонент. Отсюда и появилась идея добавить к микросервисам смысловую надстройку – бизнес-функциональность. Так возник термин Package Business Capability, или «упакованная бизнес-возможность».

«Мы впитали эту идею и поняли, что PBC отлично подходит для построения наших решений. Это не просто набор сервисов, а полноценный бизнес-модуль, который приносит ценность заказчику», – отмечает Дмитрий Старов.

PBC как новый уровень модульности

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

• один или несколько микросервисов;
• API – синхронное (REST) или событийное;
• пользовательский интерфейс (если это требуется бизнесу).

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

Если микросервис – это чисто backend-компонент, то PBC может иметь и визуальный слой. Например, интерфейс для клиента или оператора. Несколько таких PBC могут работать совместно – на одной странице или в одном приложении, обмениваясь данными через API.

Главное отличие – ориентация на бизнес

PBC проектируются вокруг конкретных бизнес-процессов.

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

Ключевые свойства PBC:

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

PBC и наследие: как сохранить прошлое

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

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

«PBC – это не всегда про новейшие технологии. Иногда это способ вдохнуть новую жизнь в старые системы, сделав их частью современной цифровой платформы», – отмечает Дмитрий Старов.

Почему бизнесу важно думать через PBC

Переход от архитектуры микросервисов к PBC – это не просто смена терминов. Это смена подхода к проектированию цифровых систем. Если микросервисы служат разработчикам, то PBC создаются для бизнеса.

Благодаря этому подходу:

• бизнес-задачи формулируются в понятных категориях – «возможностей», а не «сервисов»;
• ускоряется внедрение новых функций – каждый модуль можно адаптировать или переиспользовать;
• снижается сложность архитектуры и зависимость от конкретных технологий;
• появляется прозрачная структура, каждый элемент которой имеет измеримую бизнес-ценность.

PBC становятся новым языком взаимодействия между бизнесом и IT.

РВС позволяют проектировать системы как набор взаимосвязанных бизнес-возможностей, а не просто как набор кода и баз данных.

Принципы построения PBC в Digital Q

В экосистеме Digital Q разработка и сопровождение PBC подчинены ряду принципов, обеспечивающих качество и повторяемость процессов.

Автоматизация: минимум рутины

Разработка должна быть свободна от повторяющихся задач. В Digital Q используется low-code подход, который генерирует шаблонный код и инфраструктуру автоматически.

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

Законтрактованность: ясные связи между блоками

Когда в системе десятки или сотни PBC, необходимо, чтобы каждая из них имела ясно описанный контракт: какие события поддерживает, какие API предоставляет, в каком формате передаются данные.

Это избавляет команды разработки от необходимости каждый раз «заглядывать внутрь» сервиса и помогает повторно использовать существующие блоки.

DevOps: автоматический конвейер

Без DevOps тяжело говорить о масштабируемой архитектуре. Сотни PBC невозможно собирать и тестировать вручную.

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

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

Документируемость: знание, которое всегда под рукой

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

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

Когда эти принципы оформились, стало очевидно: для их полноценной реализации нужен единый инструмент, который объединит проектирование, генерацию, документирование и DevOps-процессы. Так появилась технологическая платформа Digital Q.Archer.

Digital Q Archer: архитектура точного попадания

Название Archer («стрелок») символизирует точность и прицельность решений, которые создаются с помощью платформы.

Платформа Digital Q.Archer – это инструмент для быстрой разработки «упакованных бизнес-возможностей» (PBC) и входящих в их состав микросервисов, обеспечивающих необходимую бизнес-функциональность.

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

Для этого в Digital Q.Archer предусмотрен «Дизайнер микросервисов». Он помогает разложить бизнес-логику по микросервисам, выделить границы контекстов и спроектировать полноценную микросервисную модель. После завершения проектирования платформа способна автоматически сгенерировать код, создать и сохранить контракты API, чтобы ими можно было пользоваться при дальнейшем развитии системы.

Digital Q.Archer интегрирован с DevOps-конвейером, что позволяет запускать сборку, тестирование и развертывание решения прямо из интерфейса платформы.

«Хочется, чтобы все происходило буквально в несколько кликов: спроектировал, нажал кнопку – и процесс завертелся. Именно это реализовано в Digital Q.Archer», – говорит Дмитрий Старов.

Как внести изменение в систему за 14 минут: реальность, а не фантастика

Платформа Digital Q.Archer позволяет за считанные минуты внести правку в рабочий процесс, сгенерировать новый код, пройти через весь DevOps-конвейер и убедиться, что изменение корректно внедрено в боевой микросервис.

Проектирование: все начинается с модели

Работа начинается в консоли Digital Q.Archer. После авторизации пользователь попадает в интерфейс платформы, где можно выбрать нужную PBC. Здесь использован модуль по обмену сообщениями в формате Банка России (УФЭБС).

Каждая PBC содержит набор бизнес-объектов – элементов логической модели, отражающих предметную область. У каждого объекта есть атрибуты: имя, тип данных, связи с другими объектами или внешними системами.

Digital Q.Archer позволяет просматривать эти объекты как в табличном виде, так и в виде графической схемы. Визуальный дизайнер помогает архитекторам легко вносить изменения: добавить атрибут, настроить связи, изменить логику.

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

Публикация и генерация кода

Следующий шаг – публикация изменений. При нажатии кнопки «Опубликовать» Digital Q.Archer запускает автоматический процесс генерации кода и документации.

Каждая PBC в платформе состоит из нескольких микросервисов. В данном примере – из трех: двух рабочих и одного композиционного, отвечающего за метаданные. После генерации система обновляет API и документацию, в том числе Swagger-спецификации. Новый параметр operation сodes сразу появляется в API, и разработчики могут его использовать.

Параллельно запускается DevOps Pipeline – автоматический конвейер, который проверяет качество кода, собирает контейнеры и развертывает обновленную версию сервиса. В реальном времени можно наблюдать за ходом выполнения: зеленые шаги показывают завершенные этапы, белые – ожидающие очередь.

Если тесты и проверка качества проходят успешно, сборка получает статус Success, а новый контейнер автоматически устанавливается в кластер Kubernetes.

Проверка результата в действии

После успешной установки микросервиса команда может сразу протестировать обновленный функционал.

Здесь использован XML-файл, содержащий новый параметр operation сodes = 1. Этот файл обработан через Digital Q.Message Hub – кросс-продуктовую платформу для обмена сообщениями.

При загрузке файла запускается бизнес-процесс обработки (BPM), один из шагов которого – вызов микросервиса, измененного в Digital Q.Archer. В результате данные преобразуются и передаются во внешнюю систему (например, Diasoft FA# Beans).

После обработки в результирующем документе действительно появится новый атрибут operation сodes = 1. Изменение, внесенное в модель, отразится в бизнес-системе – без ручного кодинга и с полным автоматическим циклом публикации.

Наблюдаемость и трассировка

Все действия, выполняемые системой, фиксируются в платформе Digital Q.ELK – инструменте мониторинга и логирования.

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

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

14 минут от правки до результата

Всего за 14 минут изменена бизнес-модель, сгенерирован код, обновлен API, запущен DevOps-конвейер, выполнено тестирование и развертывание решения, а затем проверен результат во внешней системе.

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

«Архитектор добавил параметр – платформа сделала все остальное. Это и есть настоящая автоматизация разработки», – резюмирует Дмитрий Старов.

Проверка не на словах, а на реальных продуктах

Когда речь заходит о новых платформах разработки, закономерно возникает вопрос: а как это работает в боевых условиях. Можно ли быть уверенным, что система не «проседает» под реальной нагрузкой и действительно выдерживает масштаб крупного бизнеса?

В команде Digital Q этот вопрос не оставляют без внимания. Тесты производительности – не разовая проверка, а регулярная практика.

«Если платформа работает правильно, но медленно, она никому не нужна, – отмечает Дмитрий Старов. – Поэтому мы постоянно следим за тем, как наши решения ведут себя под нагрузкой и где можно улучшить производительность».

Для оценки производительности тестировались не демопримеры, а реальные промышленные решения, созданные с использованием инструментов Digital Q, включая Digital Q.Archer. В испытаниях участвовали такие продукты, как система дистанционного банковского обслуживания (ДБО) для розничного кредитования и мобильный банкинг.

Тестирование проводилось совместно с партнерами IBM и Red Hat на их мощностях в дата-центре в Монпелье (Франция). Это не лабораторная симуляция, а полноформатная проверка с развернутой инфраструктурой и реальными сценариями пользовательской активности.

Тесты проводились на нескольких кластерах, состоящих из одной мастер-ноды и двух рабочих, с использованием привычного стека: Kafka, PostgreSQL и сервисных компонентов, генерируемых через Digital Q.

Были смоделированы три типовых профиля нагрузки:

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

Для последнего сценария заданы реальные показатели:

• 50 млн клиентов;
• 20 млн активных пользователей мобильного банка;
• 100 000 одновременных подключений в часы пик.

Даже при максимальной нагрузке система продемонстрировала устойчивую производительность – 1000 транзакций в секунду (TPS).

Для понимания: одна бизнес-транзакция – это не просто технический вызов, а полноценный бизнес-процесс. Он включает обращение к микросервису, обработку запроса, взаимодействие с базой данных или кэшем и возврат ответа пользователю.

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

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

Вместо заключения

Современные цифровые решения требуют скорости, гибкости и прозрачности. Именно поэтому архитектура, основанная на PBC, становится ключевым инструментом для компаний, стремящихся к цифровой трансформации.

Digital Q.Archer играет в этом процессе центральную роль. Платформа не просто ускоряет разработку – она делает ее управляемой, стандартизированной и предсказуемой. Благодаря единому реестру компонентов, четким контрактам и полной автоматизации DevOps-процессов команды могут быстро собирать бизнес-приложения из готовых модулей, не теряя при этом контроля над качеством и архитектурой.

Главный результат – сокращение time to market, то есть времени от идеи до выхода готового решения. Этот показатель напрямую влияет на конкурентоспособность компании: чем быстрее продукт выходит на рынок, тем раньше бизнес получает прибыль, обратную связь от клиентов и возможность адаптироваться к изменениям. Короткий цикл разработки позволяет быстрее внедрять инновации, снижать издержки и удерживать лидерство в динамичной цифровой среде.

Читайте другие материалы:

«Трактор или лопата?» — разбираем главные мифы и проблемы low-code платформ