Сила метаданных в расширяемой архитектуре продукта
Расширяемость — это архитектурное качество системы, позволяющее без дополнительных усилий добавлять в нее новые функции. Реализуется это в первую очередь за счет использования метаданных, которые играют решающую роль в создании адаптируемых и расширяемых систем.
Ключевая фраза здесь — «без дополнительных усилий». ПО, несомненно, можно расширить и приложив к этому некоторые усилия по разработке. Вопрос в том, сколько усилий это потребует.
Как метаданные могут помочь сократить эти усилия? Давайте разберемся.
Пример расширяемости модели данных
Давайте представим, что y нас есть тип данных user, и мы хотим расширить его за счет дополнительного поля. Для этого необходимо реализовать постоянное хранение данных, операции чтения и записи, контроль доступа и разрешения, параметры сортировки и фильтрации, отображение и редактирование UI и многое другое. И результат не всегда будет пропорционален усилиям.
Вполне вероятно, что у объекта user может быть несколько применений в системе, поэтому, хоть мы и добавляем только одно поле, нам может потребоваться внести изменения во все места, где отображается информация о user.
Роль метаданных
Описанный подход не является расширяемым — он требует дополнительных усилий для внесения изменений в модель данных (новое поле) в системе. Так что же это за «дополнительные» усилия? Собственно, все перечисленные усилия являются «лишними». Для добавления нового поля может не потребоваться буквально никаких усилий.
Рассмотрим реляционные базы данных (Postgres, MySQL и т. д.). Очевидно, что нам не нужно иметь дело с исходным кодом Postgres, если мы добавляем новый столбец в реляционную таблицу — мы просто используем команду ADD COLUMN. И вот новые данные можно сохранять, извлекать, обновлять, сортировать, фильтровать и т. д.
Все это возможно, потому что архитектура реляционной БД предназначена для расширения, а для достижения этой расширяемости используется концепция метаданных.
Вместо жесткого кодирования моделей данных в реляционных БД используется принцип, согласно которому все части модели данных должны быть описаны с помощью конкретных моделей метаданных — информационной_схемы. В результате логика, взаимодействующая с моделями данных, использует эти метаданные для выполнения операций с данными. Так, добавление нового поля (или таблицы) не потребует разработки — необходимо лишь правильно расширить модели метаданных.
И этот подход не ограничивается БД технологиями. Например, есть широкий спектр онлайн БД продуктов, которые предоставляют пользователям удобный веб-интерфейс для организации информации в виде таблиц.
Расширяемость в других областях
Применение расширяемости не ограничивается моделями данных. Например, мы можем добавить в систему поддержку пользовательских виджетов, задав метаданные виджета (имя, тип, место реализации и т. д.) для использования их в логике UI, чтобы обеспечить навигацию по виджетам, где нужны имя/тип, и отображение, где нужна реализация.
Реализовать расширяемую архитектуру может быть сложно, но сама идея сделать определенный аспект системы расширяемым довольно тривиальна. Мы описываем аспект с помощью модели метаданных и строим необходимые операции, полагаясь на модели метаданных, вместо того, чтобы жестко их программировать.
Расширяемая архитектура: за и против
Расширяемая архитектура не всегда лучший выбор. Когда мы делаем некоторые аспекты системы расширяемыми, то вносим дополнительный уровень абстракции — метаданные. Это, в свою очередь, сопряжено с определенными затратами.
Хорошо, если система выиграет от добавления большего количества элементов, но ситуация может быть и иной. Более распространенный сценарий — придется последовательно внедрять в систему новые функции. В таком случае построение расширяемой архитектуры может быть просто ненужным трудозатратным процессом, которого следует избегать.
Настройка, компоновка, кастомизация и шаблоны
В основе расширяемой архитектуры заложена концепция метаданных. Чтобы сделать части архитектуры расширяемыми, их нужно определить как точку расширения. Нужно сначала описать эти точки с помощью метаданных, а далее строить все операции с ними, уже используя эти метаданные.
Например, существует целый класс продуктов, которые можно рассматривать как онлайн базы данных, где используется этот подход: Airtable, Fibery, MS Lists, Google Tables и другие.
Эти продукты предлагают пользователю интерфейс, который позволяет взаимодействовать с полностью настраиваемыми табличными моделями данных.
Гибкость настройки достигается за счет того, что модель таблицы (столбцы) не жестко запрограммирована. Вместо этого она описывается с использованием метаданных, которые предоставляют информацию: имя столбца, тип данных в нем и его положение в таблице.
Табличный UI не предполагает, что предопределенные столбцы будут представлены в табличной модели. Вместо этого он считывает описание метаданных таблицы (в данном случае — список метаданных столбцов), а затем строит визуальное представление таблицы и реализует взаимодействие с интерфейсом на основе этого описания.
Давайте рассмотрим продвинутые аспекты расширяемой архитектуры на основе метаданных.
Настройка
Настройка ― возможность легко модифицировать систему путем корректировки опций и параметров.
С архитектурой на основе метаданных это можно реализовать почти сразу. Стоит разрешить пользователям менять параметры метаданных, и система сразу станет настраиваемой.
Если в продукте есть модель таблицы, описанная столбцами, а эти столбцы описаны метаданными, которые пользователям разрешено изменять, то они смогут изменять имя, тип, порядок и другие свойства столбцов. Это превращает метаданные столбца в модель настройки столбцов.
Компоновка
Компоновка ― способность системы сочетать разными способами различные компоненты для создания определенных конфигураций или наборов функций.
Даже в модели столбцов уже доступна компоновка, так как пользователь может скомпоновать в таблице любой список столбцов. Это наделяет архитектуру эмерджентными качествами, что позволяет создавать в таблице любую структуру данных.
Все вышеперечисленные продукты в реализации модели идут дальше и позволяют связывать разные таблицы между собой. Пользователь может определить столбец в одной таблице, данные которого будут ссылаться на строку из другой таблицы. Речь идет не только о составлении отдельных структур данных (таблиц) из примитивных атрибутов (столбцов), но и о составлении схем данных из нескольких таблиц, которые состоят из настраиваемых столбцов.
Это позволяет обеспечить реализацию любой возможной модели данных в форме связанных таблиц.
Конечно, компоновка касается не только моделей данных. Пользователю также может быть разрешено создавать формы ввода, правила автоматизации, визуальные представления (например, Board View), реализовав таким образом концепцию платформы для гражданских разработчиков (см. citizen developer).
Кастомизация
Кастомизация ― способность системы к модификации для удовлетворения конкретных запросов и требований через изменение ее внешнего вида, поведения или функциональности, которая часто включает создание пользовательских расширений/плагинов или изменение базового кода.
Если компоновка позволяет комбинировать уже существующие модули в различные комбинации, кастомизация позволяет создавать новые модули. Кастомизация может потребовать от пользователей навыков в промышленной разработке. Например, можно разрешить пользователю создавать действия автоматизации в JavaScript. Для этого потребуется «песочница», так как внешнему коду доверять нельзя. Однако ничто принципиально не препятствует такому подходу.
При этом кастомизация не всегда требует от пользователей навыков разработки. Новый модуль может быть создан и без этого, а затем повторно использован в различных конфигурациях другими пользователями. Например, конфигурация столбца определяет тип данных, а для пользовательских типов данных (таких как перечисления, которые затем можно повторно использовать в разных столбцах) может быть предоставлен конструктор UI.
Шаблоны
Шаблон ― это способность системы делать моментальный снимок или копию существующей конфигурации (настройки) для последующего использования или создания нескольких экземпляров исходной конфигурации.
Все перечисленные качества расширяемой архитектуры основаны на концепции метаданных, в связи с чем стоит отметить, метаданные — это данные. Можно разработать функциональность, которая будет фиксировать определенную конфигурацию метаданных в модели данных, а затем использовать эту модель для воспроизведения исходной конфигурации в новых копиях.
Шаблоны в расширяемой архитектуре важны: они позволяют создавать конфигурации для использования при решении повторяющихся проблем. Это устраняет необходимость создавать новую конфигурацию каждый раз с нуля.
Заключение
Концепция метаданных — основа расширяемой архитектуры, которая позволяет дополнительно улучшить архитектуру за счет имплементации настроек, компоновки, кастомизации и использования шаблонов.
