Корпоративные автоматизированные системы обычно строятся по классической трехуровневой архитектуре, которая разделяет слои клиента (представления), логики и хранения данных. Такой подход проверен временем, но его главной проблемой является сложность внесения изменений, связанных с модификацией структуры данных. В таких случаях приходится вносить изменения во все три слоя, что на практике чаще всего означает редактирование структуры базы данных, модификацию кода серверной части, сервисов для взаимодействия с клиентской частью и самого клиента. Актуально это и для систем, построенных по микросервисной архитектуре, где изменение структуры данных может затронуть сразу несколько сервисов.
Существует множество инструментов и техник для внесения скоординированных изменений во все слои приложения, но это в любом случае требует значительных трудозатрат и сильно влияет на структуру процессов разработки и развертывания. Можно ли построить такую архитектуру автоматизированной системы, которая упростит и ускорит реализацию изменений, связанных со структурой данных?
Наш опыт создания подобных систем позволяет говорить о том, что построение автоматизированной системы вокруг данных, а не логики их обработки, позволяет достичь этой цели. Предлагаемый подход является воплощением идеи дата-центричной архитектуры на уровне конкретного приложения. Кратко описать наш подход можно следующими тезисами:
данные существуют сами по себе и не должны зависеть от автоматизированных систем, которые с ними работают, "принадлежать" какой-то конкретной системе;
структура данных так же изменчива, как и сами данные, и не должна быть жестко связана с программным кодом - код должен быть готов к изменению структуры данных;
логику обработки данных желательно, насколько возможно, отделить от программного кода и сделать настраиваемой.
Представим, что в центре архитектуры автоматизированной системы находится слой хранения данных, который обеспечивает следующие функции:
мульти-модельное хранение структурированных данных в различных физических хранилищах и абстрагирование кода приложения от деталей хранения (виртуализацию данных) путем предоставления универсального API для работы с ними. Подчеркнем, что это противоположно технологии ORM, которая, наоборот, связывает внутреннюю структуру кода приложения со структурой данных в хранилище;
программный интерфейс для считывания и изменения структуры данных;
механизм уведомлений программных компонентов об изменениях в данных и их структуре во время выполнения приложения (например, подписка через менеджеры очередей);
хранение и предоставление через API истории изменения данных и их структуры (версионность), планирование будущих изменений в данных;
встроенные механизмы контроля логической целостности данных и их обогащения.
Программный код, реализующий логику приложения, при работе с таким хранилищем данных приобретает важные свойства. Он не должен содержать классов ООП, структура которых повторяет структуру данных, потому что структура данных может измениться по ходу работы приложения, и тем более не должен использовать ORM, которая "отливает в бетоне" связь между кодом и структурой данных. Вместо этого код и сервисы обмена данными между компонентами должны быть предельно абстрактными, готовыми к изменению структуры данных в определенных пределах. Это значит, что и логика обработки конкретных типов объектов или их свойств должна быть формализована вне кода и доступна для изменения во время выполнения приложения.
Для реализации подобной архитектуры необходим механизм машинно-читаемого представления структуры данных и логики их обработки. На наш взгляд, одним из наиболее подходящих для этого средств являются спецификации онтологического моделирования RDF/RDFS/OWL. С точки зрения этих спецификаций структура данных, сами данные и элементы логики их обработки технологически однородны, т.е. могут храниться и редактироваться одними и теми же средствами.
Значительная часть формального описания логики исполнения приложения может быть перенесена из кода на уровень онтологической модели, выразительных средств которой достаточно для описания алгоритмов вычислений и обогащения данных (см., напр., спецификацию SHACL Advanced Features), правил преобразования данных, правил предоставления доступа, отображения визуального интерфейса и многого другого. Явных ограничений здесь нет, в онтологической модели можно представить любую часть логики приложения, сделав осознанный выбор в пользу гибкости приложения в обмен на повышенную сложность разработки программного кода, интерпретирующего такую модель.
Рассмотрим на примере, как может быть построена работа приложения с такой архитектурой. Пусть необходимо создать приложение для автоматизации обычного бизнес-процесса, такого как открытие магазина торговой сети. Процесс включает несколько стадий, на которых сотрудники разных ролей выполняют задачи подбора помещения, согласования и выполнения его ремонта и оформления, подбора персонала и др. Все они работают с разными представлениями информации об объектах одних и тех же типов, таких как помещение, сотрудник, подрядчик, документ и др. В ходе выполнения процесса информация о конкретных объектах этих типов создается, обогащается и трансформируется. Нужно построить приложение, которое позволит пользователям разной квалификации видеть только необходимые им данные в списках и карточках каждого объекта, отражать в системе результаты выполнения своих задач и передавать процесс на следующие стадии.
Ядром создаваемой системы будет онтологическая модель предметной области, в которой прежде всего нужно описать типы бизнес-объектов и их свойства. Также она будет включать модель самого бизнес-процесса, описывающую его стадии, правила перехода между ними, свойства бизнес-объектов, значения которых заполняются на каждой стадии процесса, наборы типов прикрепляемых документов. Программный код должен интерпретировать модель в ходе выполнения и немедленно реагировать на изменение состава данных, логики их обработки, правил визуального представления.
Все эти элементы будут редактироваться аналитиками через редактор онтологии, и в машинно-читаемом виде будут доступны программному коду через API платформы виртуализации данных. В качестве API для взаимодействия компонентов приложения с платформой виртуализации данных и между собой может использоваться, например, GraphQL - с учетом того, что структура типов сущностей, связей и свойств описана в онтологии и может изменяться.
Теперь представим, что бизнес-процесс изменился из-за появления новых нормативных требований - например, необходимо проходить еще один вид согласований, сопровождающийся оформлением документов новых типов. Для внесения изменений в автоматизированную систему достаточно создать в онтологической модели описание нового шага процесса, правила перехода к нему, новые типы документов, их возможные связи с объектами других типов, правила отображения в пользовательском интерфейсе. Все эти изменения можно запланировать к вступлению в силу в определенный момент с помощью функций платформы виртуализации данных. В назначенное время программные компоненты получат от платформы уведомления об изменении структуры данных и правил их обработки, и должны будут немедленно изменить логику своей работы. Это не потребует ни обновления кода компонентов, ни даже перезапуска приложения. Изменения в модель будут вносить не программисты, а аналитики - почти как в Low code платформах, только в более общем/стандартном виде и без привязки к проприетарному решению. В результате реализация, отладка и доставка изменений потребуют меньше времени и ресурсов, чем при классическом подходе.
Мы не настаиваем на том, чтобы полностью исключить из кода приложения любую привязку к предметной области. Если какие-то типы объектов можно считать "константами" для данного бизнес-процесса, как, например, сущность "магазин" для процесса открытия магазина - упоминание этих сущностей в коде не нарушит стройности подхода. Однако приложение должно быть готово к появлению новых подклассов этих сущностей, обладающих разными свойствами (например, у магазинов разных форматов набор свойств может отличаться), новых свойств и связей, изменению логики их обработки.
Какие преимущества обеспечит предлагаемая архитектура и инструментарий?
Возможность изменять поведение системы, структуру данных и логику их обработки без обновления программного кода и перезапуска приложения.
Большую часть изменений в работу системы будут вносить аналитики, а не программисты.
Возможность включения объекта одновременно в несколько классов (отнесения объекта к нескольким типам) и возможность выделения подклассов объектов, которые обеспечивает онтологическое моделирование, обеспечивают гибкость формирования наборов свойств объектов. Так, одно и то же физическое лицо на разных стадиях процесса может рассматриваться как кандидат, контактное лицо со стороны внешнего контрагента, сотрудник, руководитель, собственник и др., причем каждому из этих статусов соответствует особый набор применимых свойств и отношений с объектами других типов.
Сервисы в микросервисной архитектуре смогут сократить затраты ресурсов на обработку и передачу данных, поскольку будут работать с данными в общем хранилище.
Все это в целом снизит затраты на разработку и стоимость владения системой, повысит скорость предоставления полезных функций бизнес-пользователям, несмотря на то, что затраты на первоначальное создание универсального кода вырастут, а проектированию онтологической модели придется уделить существенное внимание.
Наиболее ярко преимущества подхода проявятся при создании аналитических систем, а также приложений, работающих с данными очень сложной и изменчивой структуры, таких как ПО ситуационных центров. Тем не менее, разумеется, предложенная архитектура - лишь один из возможных вариантов решения подобных задач. В каждом конкретном случае необходимо выбирать наиболее подходящий вариант исходя из прогноза частоты и масштаба предполагаемых изменений требований к системе, которые потребуют изменения структуры данных и логики их обработки.
Создав приложение по описанным принципам, мы обнаружим, что открыли путь к реализации полноценной дата-центричной архитектуры предприятия, в которой множество приложений одновременно работают с одним и тем же набором информации, находящимся под управлением платформы виртуализации данных. Это позволит забыть о проблемах с интеграцией и сосредоточиться на реализации полезных функций приложений. В частности, откроется возможность создания микро-фронт-эндов для быстрого решения задач пользователей без усложнения ИТ-архитектуры предприятия, создания лишних копий наборов данных и интеграционных процедур.
