Уровни низкого кода и абстракции

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

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

3 основных уровня

Когда вы программируете, вы всегда имеете дело с тремя разными абстракциями. Эти:

Уровень возможностей: возможности приложения. Описывает, что приложение может делать и какие инструменты находятся в наборе инструментов (с какими степенями свободы).
На уровне поведения: поведение приложения. Описывает, что необходимо сохранить и выполнить для достижения бизнес-цели.
Уровень использования: использование приложения. Включает в себя все, что создается при использовании двух других уровней в живой среде.

Давайте посмотрим, что делают эти уровни в стандартной архитектуре приложений, а также в архитектурах с низким или отсутствующим кодом.

Уровни в стандартных приложениях

В стандартном приложении уровни возможностей и поведения объединены и записаны в коде приложения + отдельная структура сохраняемости. Таким образом, эти уровни охватывают как возможности (общие функции), так и поведение (бизнес-функции). Уровень возможностей часто имеет форму разделения путем создания и использования компонентов / библиотек, которые фиксируют общие возможности. Повторное использование в вашем приложении здесь должно быть самым высоким. Классы библиотеки Java являются примером обеспечения функциональности на уровне возможностей.

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

Гибкость

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

«… но наш компонент другой».
«Нам нужна эта особая функция в очереди, чтобы скопировать ее и создать нашу собственную версию».
«Это совершенно новый интерфейс, которого никогда раньше не было, поэтому нам нужно написать свой собственный».

Дело в том, что гибкость наличия уровней возможностей и поведения на одном языке позволяет разработчикам пересекать границы между двумя уровнями (и часто не осознают, что это делают). И это может быть хорошо! Например, для увеличения производительности. Однако, когда этот флажок не установлен, причины для этого не обязательно должны быть обоснованными архитектурными / дизайнерскими решениями.

Использовать

На уровне использования хранилище делится на две части: долгосрочное (постоянство) и краткосрочное (использование). В то время как долгосрочные часто представляют собой какую-то базу данных, в которой хранятся все данные, необходимые приложению для хранения текущего состояния бизнеса. Краткосрочно хранит данные, когда обрабатывает изменения в этом состоянии бизнеса.

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

Уровни в фреймворке Low-code

Уровни абстракции в средах с низким кодом делятся на три уровня, указанные выше. Это разделяет определение возможностей и поведения. Более того, большинство платформ с низким кодом (Blueriq, Будьте в курсе, Mendix, Outsystems и другие) имеют исполняемый файл времени разработки и исполняемый файл. Во время разработки возможности можно использовать для создания модели, которая определяет поведение, которое приложение должно проявлять. Когда модель загружается во время выполнения, поведение становится доступным пользователю.

Другие платформы полностью контролируют стек и являются облачными, например, BettyBlocks. Хотя Mendix также предлагает это как дополнительную услугу.

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

Гибкость

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

Однако, если вы хотите использовать больше возможностей, чем предусмотрено во фреймворке, у вас будет два варианта с соответствующими проблемами:

1. Расширьте возможности модели.

Да, велики шансы, что вы сможете реализовать недостающие возможности языка моделирования. Вероятность также ~ 99%, что язык моделирования не предназначен для этого. Если команды построят эти возможности в модели, это затронет некоторые нефункциональные элементы; Это снизит ремонтопригодность (и увеличит сложность), может снизить производительность и гибкость.

2. Расширьте возможности фреймворка

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

Bettyblocks, например, рекламируется как платформа без кода. И хотя сама платформа может не содержать кода, специализированный контент (например, функции ГИС) необходимо создавать или получать из других источников через API.

Использовать

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

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

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

Создание гибрида

Если вы чувствуете, что находитесь на распутье, вопрос будет следующим: как далеко вы хотите спуститься в кроличью нору?

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

Если вы хотите иметь одну возможность приложения в (более) среде с низким кодом и с другим языком, скорее всего, для этого уже есть библиотека. Например: Правила-движки для java. Этот пример уже исходит из того, что над поведением вашего приложения работают только разработчики, но сохраняет части, которые не изолированы от конкретной области знаний. И если это не открытый исходный код, вы станете зависимым от цикла выпуска библиотеки / плагина. Более сложные возможности, такие как система управления делами, подразумевают гораздо большую зависимость и, вероятно, платный продукт.

Внесение нескольких (или всех, если на то пошло) аспектов в архитектуру с низким кодом потребует очень хорошего понимания нефункциональных функций, которые необходимы; Производительность, ремонтопригодность и т. Д. Во многом определяются на уровне возможностей. И язык (и) на уровне модели должен быть в состоянии выражать, удерживать и обслуживать все возможности, которые вы хотите внедрить в эту архитектуру с низким кодом. Разделение будет большим преимуществом, но также может стать ахиллесовой пятой, когда будут предоставлены возможности, которые немного не соответствуют.

Заключение

При рассмотрении архитектуры или фреймворка с низким кодом внезапно возникает много интересного. Необходимо учитывать как сторону разработки, так и производственную часть спектра: какие возможности действительно необходимы (сейчас и в будущем)? Как будет указано поведение? Как это будет выражаться, храниться, выпускаться, развертываться и выполняться? Какие роли и навыки необходимы для создания и развертывания?

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

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

Заключительное примечание:… он не такой черно-белый, как здесь! Может быть много других причин использовать уровни абстракции. Чтобы назвать два:

.NET Framework не совсем стандартный. Он использует уровень абстракции в форме промежуточного языка (CIL) для кросс-платформенной и языковой совместимости ... и это тоже не low-code, потому что другие принципы программирования такие же, как и в стандартной модели (она по-прежнему компилируется и развертывается как стандартное приложение + его установка .NET framework).
Я работал в отделе технической автоматизации, где среды с низким кодом используют (графический) язык моделирования для определения поведения всей системы / продукта. Он компилируется (по причинам производительности и возможностей оборудования) в машинный код для набора определенных подсистем / наборов микросхем, работающих вместе в унисон.

Уровни низкого кода и абстракции