Корпоративные автоматизированные системы обычно строятся по классической трехуровневой архитектуре, которая разделяет слои клиента (представления), логики и хранения данных. Такой подход проверен временем, но его главной проблемой является сложность внесения изменений, связанных с модификацией структуры данных. В таких случаях приходится вносить изменения во все три слоя, что на практике чаще всего означает редактирование структуры базы данных, модификацию кода серверной части, сервисов для взаимодействия с клиентской частью и самого клиента. Актуально это и для систем, построенных по микросервисной архитектуре, где изменение структуры данных может затронуть сразу несколько сервисов.
Существует множество инструментов и техник для внесения скоординированных изменений во все слои приложения, но это в любом случае требует значительных трудозатрат и сильно влияет на структуру процессов разработки и развертывания. Можно ли построить такую архитектуру автоматизированной системы, которая упростит и ускорит реализацию изменений, связанных со структурой данных?
Наш опыт создания подобных систем позволяет говорить о том, что построение автоматизированной системы вокруг данных, а не логики их обработки, позволяет достичь этой цели. Предлагаемый подход является воплощением идеи дата-центричной архитектуры на уровне конкретного приложения. Кратко описать наш подход можно следующими тезисами:
данные существуют сами по себе и не должны зависеть от автоматизированных систем, которые с ними работают, "принадлежать" какой-то конкретной системе;
структура данных так же изменчива, как и сами данные, и не должна быть жестко связана с программным кодом - код должен быть готов к изменению структуры данных;
логику обработки данных желательно, насколько возможно, отделить от программного кода и сделать настраиваемой.
Представим, что в центре архитектуры автоматизированной системы находится слой хранения данных, который обеспечивает следующие функции:
мульти-модельное хранение структурированных данных в различных физических хранилищах и абстрагирование кода приложения от деталей хранения (виртуализацию данных) путем предоставления универсального API для работы с ними. Подчеркнем, что это противоположно технологии ORM, которая, наоборот, связывает внутреннюю структуру кода приложения со структурой данных в хранилище;
программный интерфейс для считывания и изменения структуры данных;
механизм уведомлений программных компонентов об изменениях в данных и их структуре во время выполнения приложения (например, подписка через менеджеры очередей);
хранение и предоставление через API истории изменения данных и их структуры (версионность), планирование будущих изменений в данных;
встроенные механизмы контроля логической целостности данных и их обогащения.
Программный код, реализующий логику приложения, при работе с таким хранилищем данных приобретает важные свойства. Он не должен содержать классов ООП, структура которых повторяет структуру данных, потому что структура данных может измениться по ходу работы приложения, и тем более не должен использовать ORM, которая "отливает в бетоне" связь между кодом и структурой данных. Вместо этого код и сервисы обмена данными между компонентами должны быть предельно абстрактными, готовыми к изменению структуры данных в определенных пределах. Это значит, что и логика обработки конкретных типов объектов или их свойств должна быть формализована вне кода и доступна для изменения во время выполнения приложения.
Для реализации подобной архитектуры необходим механизм машинно-читаемого представления структуры данных и логики их обработки. На наш взгляд, одним из наиболее подходящих для этого средств являются спецификации онтологического моделирования RDF/RDFS/OWL. С точки зрения этих спецификаций структура данных, сами данные и элементы логики их обработки технологически однородны, т.е. могут храниться и редактироваться одними и теми же средствами.
Значительная часть формального описания логики исполнения приложения может быть перенесена из кода на уровень онтологической модели, выразительных средств которой достаточно для описания алгоритмов вычислений и обогащения данных (см., напр., спецификацию SHACL Advanced Features), правил преобразования данных, правил предоставления доступа, отображения визуального интерфейса и многого другого. Явных ограничений здесь нет, в онтологической модели можно представить любую часть логики приложения, сделав осознанный выбор в пользу гибкости приложения в обмен на повышенную сложность разработки программного кода, интерпретирующего такую модель.
Рассмотрим на примере, как может быть построена работа приложения с такой архитектурой. Пусть необходимо создать приложение для автоматизации обычного бизнес-процесса, такого как открытие магазина торговой сети. Процесс включает несколько стадий, на которых сотрудники разных ролей выполняют задачи подбора помещения, согласования и выполнения его ремонта и оформления, подбора персонала и др. Все они работают с разными представлениями информации об объектах одних и тех же типов, таких как помещение, сотрудник, подрядчик, документ и др. В ходе выполнения процесса информация о конкретных объектах этих типов создается, обогащается и трансформируется. Нужно построить приложение, которое позволит пользователям разной квалификации видеть только необходимые им данные в списках и карточках каждого объекта, отражать в системе результаты выполнения своих задач и передавать процесс на следующие стадии.
Ядром создаваемой системы будет онтологическая модель предметной области, в которой прежде всего нужно описать типы бизнес-объектов и их свойства. Также она будет включать модель самого бизнес-процесса, описывающую его стадии, правила перехода между ними, свойства бизнес-объектов, значения которых заполняются на каждой стадии процесса, наборы типов прикрепляемых документов. Программный код должен интерпретировать модель в ходе выполнения и немедленно реагировать на изменение состава данных, логики их обработки, правил визуального представления.
Все эти элементы будут редактироваться аналитиками через редактор онтологии, и в машинно-читаемом виде будут доступны программному коду через API платформы виртуализации данных. В качестве API для взаимодействия компонентов приложения с платформой виртуализации данных и между собой может использоваться, например, GraphQL - с учетом того, что структура типов сущностей, связей и свойств описана в онтологии и может изменяться.
Теперь представим, что бизнес-процесс изменился из-за появления новых нормативных требований - например, необходимо проходить еще один вид согласований, сопровождающийся оформлением документов новых типов. Для внесения изменений в автоматизированную систему достаточно создать в онтологической модели описание нового шага процесса, правила перехода к нему, новые типы документов, их возможные связи с объектами других типов, правила отображения в пользовательском интерфейсе. Все эти изменения можно запланировать к вступлению в силу в определенный момент с помощью функций платформы виртуализации данных. В назначенное время программные компоненты получат от платформы уведомления об изменении структуры данных и правил их обработки, и должны будут немедленно изменить логику своей работы. Это не потребует ни обновления кода компонентов, ни даже перезапуска приложения. Изменения в модель будут вносить не программисты, а аналитики - почти как в Low code платформах, только в более общем/стандартном виде и без привязки к проприетарному решению. В результате реализация, отладка и доставка изменений потребуют меньше времени и ресурсов, чем при классическом подходе.
Мы не настаиваем на том, чтобы полностью исключить из кода приложения любую привязку к предметной области. Если какие-то типы объектов можно считать "константами" для данного бизнес-процесса, как, например, сущность "магазин" для процесса открытия магазина - упоминание этих сущностей в коде не нарушит стройности подхода. Однако приложение должно быть готово к появлению новых подклассов этих сущностей, обладающих разными свойствами (например, у магазинов разных форматов набор свойств может отличаться), новых свойств и связей, изменению логики их обработки.
Какие преимущества обеспечит предлагаемая архитектура и инструментарий?
Возможность изменять поведение системы, структуру данных и логику их обработки без обновления программного кода и перезапуска приложения.
Большую часть изменений в работу системы будут вносить аналитики, а не программисты.
Возможность включения объекта одновременно в несколько классов (отнесения объекта к нескольким типам) и возможность выделения подклассов объектов, которые обеспечивает онтологическое моделирование, обеспечивают гибкость формирования наборов свойств объектов. Так, одно и то же физическое лицо на разных стадиях процесса может рассматриваться как кандидат, контактное лицо со стороны внешнего контрагента, сотрудник, руководитель, собственник и др., причем каждому из этих статусов соответствует особый набор применимых свойств и отношений с объектами других типов.
Сервисы в микросервисной архитектуре смогут сократить затраты ресурсов на обработку и передачу данных, поскольку будут работать с данными в общем хранилище.
Все это в целом снизит затраты на разработку и стоимость владения системой, повысит скорость предоставления полезных функций бизнес-пользователям, несмотря на то, что затраты на первоначальное создание универсального кода вырастут, а проектированию онтологической модели придется уделить существенное внимание.
Наиболее ярко преимущества подхода проявятся при создании аналитических систем, а также приложений, работающих с данными очень сложной и изменчивой структуры, таких как ПО ситуационных центров. Тем не менее, разумеется, предложенная архитектура - лишь один из возможных вариантов решения подобных задач. В каждом конкретном случае необходимо выбирать наиболее подходящий вариант исходя из прогноза частоты и масштаба предполагаемых изменений требований к системе, которые потребуют изменения структуры данных и логики их обработки.
Создав приложение по описанным принципам, мы обнаружим, что открыли путь к реализации полноценной дата-центричной архитектуры предприятия, в которой множество приложений одновременно работают с одним и тем же набором информации, находящимся под управлением платформы виртуализации данных. Это позволит забыть о проблемах с интеграцией и сосредоточиться на реализации полезных функций приложений. В частности, откроется возможность создания микро-фронт-эндов для быстрого решения задач пользователей без усложнения ИТ-архитектуры предприятия, создания лишних копий наборов данных и интеграционных процедур.
Комментарии (40)
atc
04.09.2021 19:56+1Чем описываемое отличается от dynamics 365/sap или даже ms access?
SergeIndex Автор
04.09.2021 20:16+1Прежде всего - отсутствием привязки к конкретной платформе разработки ПО, возможность использовать любые языки и среды программирования.
Кроме того, ни в SAP, ни в Dynamics, ни в Access, насколько мне известно, нет тех возможностей, которые перечислены в статье: мульти-модельное хранение данных, ведение истории/версионность модели и данных (имеется в виду возможность одновременно работать с несколькими версиями модели и данных, а не переключаться между ними), возможность управления моделью данных со стороны программных компонентов, уведомление компонентов об изменении модели данных во время исполнения. Хранение логики исполнения вне кода в перечисленных вами системах в каком-то виде присутствует, но в весьма ограниченном объеме (программирование на встроенном языке нельзя считать переносом логики из кода).
Ndochp
05.09.2021 22:30+1Это как работать с несколькими версиями данных одновременно?
- Это Петя, он же Сережа, он должен нашей компании 150к рублей, или 200к неизвестно чего, так как в этой версии модели мы валюты не прикрутили, в общем как посмотреть.
(про хранить историю я понимаю, но несколько актуальных версий данных… Примерно так же не представляю как несколько одновременных моделей, типа мы ввели новый обязательный реквизит, но те клиенты, что еще не реализовали новую версию модели могут его не заполнять. Это как вообще?)
SergeIndex Автор
06.09.2021 10:14Пример про несколько версий данных: пусть у нас есть справочник тарифов, с 01.01.2022 тарифы должны измениться. Такое изменение планируется заранее. В системе должны быть программно доступны и старая, и новая версия тарифов. Алгоритмы биллинга должны ночью на 1 января автоматически перейти на расчет по новым тарифам. Поскольку система хранит данные "в 4D", в ней одновременно существуют и старые тарифы, и новые. При запросе к API системы клиент может указать метку времени и получить тарифы, актуальные на это время. Если метку не указать, то вернутся значения, актуальные на текущее время - это обеспечит автоматическое переключение на новые тарифы.
Про историю модели: клиент при работе через API может явно указать, что хочет использовать не текущую версию модели, а версию, актуальную на заданное им время. При этом сами данные одни и те же. В таком случае, да, может возникнуть ситуация, что в одной версии модели какой-то атрибут не обязателен, а в другой обязателен.
Ndochp
06.09.2021 12:29Ясно, недопонимание в терминах. С моей точки зрения это единые данные "график цен", а с вашей — версии данных — прайслисты на разное время.
Но называть средства поддержки старых версий АПИ в новой модели данных "разными моделями данных в системе" я все равно против.
Ndochp
06.09.2021 12:52Возвращаюсь получив пояснения на уровень выше:
Если понимать мультимодельное хранение данных как разные АПИ для разных клиентов, то это просто разные АРМы для разных ролей — глядя на тот же отпуск табельщик видит только даты, а расчетчик обогащает суммами отпускных — ура, у нас разная модель для разных пользователей.
Ну а регистр курсов валют — это точно присутсвующее в любой учетной системе версионирование данных.
И вообще, 1С — это программа на C, где код максимально отделен от данных. Ну конфигурируется на DSL. В 6.0 довольно примитивном, хватит аналитиков, 7.7 посложнее, но типовые операции может настроить и бухгалтер. 8.3 — ой, мы уже программ не на C, а на BSL. Что думаю в итоге ждет и вашу систему.
Кстати, глядя на 1С Документооборот — все идет на второй круг. А давайте внедрим конструктор бизнес процессов и бизнес событий (и реакций на них), в котором можно обойтись без программиста (ладно, для сложных ситуаций оставим возможность вставок на DSL). И виды документов тоже будем в пользовательском режиме настраивать.
Итог прежний — все, что чуть сложнее линейной обработки заказа делают программисты, но матерясь, что у них отняли IDE. И не стоит называть этих ребят аналитиками. Аналитики заканчиваются в Visio.SergeIndex Автор
06.09.2021 18:33Тут, видимо, можно долго спорить о терминологии "программисты"/"аналитики". Также понятно, что хочется обсуждаемое явление свести к тому, что уже известно. Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
Я понимаю, что одной статьей сложно убедить всех в том, что то, что толком не получилось у Low code платформ, можно сделать другим способом, не создавая очередного внутриплатформенного языка программирования (онтологическая модель - это не код даже в том смысле, в котором им является язык 1С).
Все, на что я надеюсь - что кто-то из читателей заинтересуется онтологическим моделированием, почитает про него и подумает над тем, как можно применять такие модели в программных продуктах.
lair
06.09.2021 19:55-1Хотя лично я не могу называть программистами людей, которые работают только с редактором онтологии и не написали за свою жизнь ни строчки программного кода.
А как в "редакторе онтологии" задается правило "сумма заказа равна сумме всех его строк + доставка (но если сумма больше X, то доставка бесплатная)"?
SergeIndex Автор
06.09.2021 20:19Можно описать как SHACL Rule, см. спецификацию https://www.w3.org/TR/shacl-af/
Редактируется с помощью визуального конструктора формул и правил, если он есть в составе платформы, на которой ведется разработка (таких платформ существует несколько), или путем ручного создания элементов онтологии. Можно хоть в Protege создать, при желании - это базовый open source редактор онтологий.
lair
06.09.2021 20:36-1А можете наглядный пример показать?
Потому что я открыл спецификацию по вашей ссылке, и увидел там вот такое (самое близкое к задаче):
ex:RectangleRulesShape a sh:NodeShape ; sh:targetClass ex:Rectangle ; sh:rule [ a sh:TripleRule ; sh:subject sh:this ; sh:predicate ex:area ; # Computes the values of the ex:area property at the focus nodes sh:object [ ex:multiply ( [ sh:path ex:width ] [ sh:path ex:height ] ) ; ] ; sh:condition ex:RectangleShape ; # Rule only applies to Rectangles that conform to ex:RectangleShape ] .(я даже не буду брать примеры с SPARQL)
SergeIndex Автор
07.09.2021 08:21Да, это похожий пример. И пример со SPARQL был бы валиден, у нас для таких есть конструктор.
Приведенная запись - один из вариантов сериализации онтологии. Есть и другие варианты, например в RDF/XML или OWL/XML. Все они при импорте в графовую СУБД дают один и тот же набор триплетов, и при просмотре через редактор выглядят одинаковым образом.
Вы можете зарегистрироваться на https://webprotege.stanford.edu или скачать десктопную версию Protege, загрузить туда этот фрагмент и посмотреть, как он будет выглядеть в редакторе. Увидите иерархию классов, среди которых будут классы NodeShape, RectangleShape, TripleRule и т.д., и индивидуальные объекты этих классов, представляющие конкретное правило.
lair
07.09.2021 09:40-1А теперь давайте рассмотрим следующее изменение требований: доставку могут осуществлять разные перевозчики, для некоторых из них расчет суммы доставки открытый (и, как следствие, должен быть в нашей системе), а для некоторых — закрытый, и делается через вызов поставляемого перевозчиком веб-сервиса. Нужно, чтобы в заказе использовался перевозчик, дающий минимальную стоимость доставки, а финальная стоимость заказа должна считаться с учетом этой стоимости.
Какие действия и кто должен совершить, чтобы реализовать это изменение?
SergeIndex Автор
07.09.2021 09:54Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы. Напомню, я не говорил в статье о том, что код полностью заменяется на модель - заменяется в некоторой части.
Если при проектировании подумали о том, что могут существовать перевозчики с закрытым алгоритмом расчета, то в модели должна быть описана сущность "внешний веб-сервис". Здесь уже стандартными спецификациями не обойтись. Для каждого сервиса формально описываются параметры и возвращаемое значение - что-то вроде SHACL Function, только для самого расчета вместо SPARQL-запроса нужно будет делать вызов внешнего сервиса.
К каждому перевозчику в модели привязываем метод расчета стоимости - это может быть SHACL Rule / Function или конкретный "внешний веб-сервис". Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
Если при проектировании о таком варианте не подумали, значит предстоит рефакторинг кода и модели.
lair
07.09.2021 09:57-1Возможность внести такое изменение только средствами моделирования зависит от того, подумали ли об этом при проектировании системы.
Конечно же, не подумали. Нельзя обо всем подумать заранее.
Алгоритм выбора перевозчика для конкретного заказа, вполне вероятно, останется в коде и будет заключаться в асинхронном запуске расчета стоимости для всех перевозчиков согласно определенным в модели алгоритмам.
… видите, даже вы употребляете слово "алгоритм".
Меня удивляет, если честно, как вы продолжаете называть людей, которые делают такие решения — описания параметров, возвращаемых значений, их преобразование, операции над ними, и все это на машинно-интерпретируемом языке — не программистами. Для меня эта активность — и есть программирование (точнее, "разработка ПО"). Но я уже не первый раз вижу, как ее исполнителей пытаются назвать аналитиками, и никак не могу понять, почему.
lair
04.09.2021 20:33+4Для внесения изменений в автоматизированную систему достаточно создать в онтологической модели описание нового шага процесса, правила перехода к нему, новые типы документов, их возможные связи с объектами других типов, правила отображения в пользовательском интерфейсе.
… ну то есть запрограммировать новый процесс.
Изменения в модель будут вносить не программисты, а аналитики — почти как в Low code платформах, только в более общем/стандартном виде и без привязки к проприетарному решению.
Гм, а как вы проводите разделение между аналитиками и программистами?
В результате реализация, отладка и доставка изменений потребуют меньше времени и ресурсов, чем при классическом подходе.
Это утверждение нуждается в формализуемой проверке.
SergeIndex Автор
04.09.2021 22:00… ну то есть запрограммировать новый процесс.
Можно запрограммировать (точнее, формально описать в онтологии) новый процесс, можно модифицировать существующий.
Гм, а как вы проводите разделение между аналитиками и программистами?
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики - это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто - в виде формальных правил в онтологии.
Это утверждение нуждается в формализуемой проверке.
Я всего лишь обобщаю наш собственный опыт разработки в соответствии с предложенным подходом. В нашей практике есть конкретные подтверждения: например, когда весной 2020 года вдруг (совершенно неожиданно) началась пандемия, в одной из сопровождаемых нами систем понадобилось обрабатывать новые виды объектов, связанные с ней (тесты, самоизоляцию и т.д.). Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
lair
04.09.2021 22:06+1Можно запрограммировать (точнее, формально описать в онтологии)
Мой пойнт как раз в том, что ваше "формально описать" — это и есть программирование.
Это хороший вопрос: в разных компаниях под аналитиками понимают разное. У нас аналитики — это прежде всего те, кто работает с онтологической моделью. Они описывают структуру данных и способы их обработки, часто — в виде формальных правил в онтологии.
То есть, на самом деле, программисты. Иными словами, ваше противопоставление "изменения в модель будут вносить не программисты, а аналитики" теряет всякий смысл.
Благодаря архитектуре системы удалось вывести структуру данных и логику обработки таких объектов в продуктив буквально за пару недель, и затем неоднократно изменять вслед за вводом/отменой различных противоэпидемических мер. Если бы у нас был классический цикл разработки, так быстро мы бы это не сделали.
Проблема в том, что это ваш опыт. То есть вы выкатываете решения на своей платформе быстрее, чем вы же выкатили бы "в классическом цикле разработки". Это ничего не говорит о том, за сколько бы выкатила другая команда, работающая "в классическом цикле".
SergeIndex Автор
04.09.2021 22:15Мой пойнт как раз в том, что ваше "формально описать" — это и есть программирование.
Тут, наверное, могут быть разные мнения. Для меня программирование - это написание кода, а манипуляции с элементами онтологической модели - не программирование. Допускаю, что можно считать иначе.
То есть, на самом деле, программисты. Иными словами, ваше противопоставление "изменения в модель будут вносить не программисты, а аналитики" теряет всякий смысл.
Да нет, почему. У нас в компании программисты и аналитики - разные люди с разной квалификацией, я их не путаю) И зарплаты у них разные.
Проблема в том, что это ваш опыт. То есть вы выкатываете решения на своей платформе быстрее, чем вы же выкатили бы "в классическом цикле разработки". Это ничего не говорит о том, за сколько бы выкатила другая команда, работающая "в классическом цикле".
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе. Никаких обобщений)
lair
04.09.2021 22:29+1Тут, наверное, могут быть разные мнения. Для меня программирование — это написание кода, а манипуляции с элементами онтологической модели — не программирование.
Написание кода — это кодирование. А программирование — это, гм, способ получить работающую программу.
У нас в компании программисты и аналитики — разные люди с разной квалификацией, я их не путаю
Просто это опять ваша компания и ее специфика.
Разумеется, я и не говорю ничего про другие команды. Я привел цикл наблюдений: у нас получилось вот так, а у отдельных других известных мне команд не получилось при другом подходе.
Вы себе противоречите: сначала "я и не говорю ничего про другие команды", а потом "у других команд не получилось".
Я могу заметить, просто для информации, что я тоже видел случаи, когда команды, у которых модель должны были описывать аналитики без участия программистов (это частое обещание в индустрии), не справлялись там, где традиционная разработка справлялась.
Поэтому я и сказал, что ваше утверждение нуждается в формализуемой проверке — а иначе его ценность для других, гм, сомнительна.
pankraty
05.09.2021 14:09Согласен с @lair по всем пунктам. Доводилось наблюдать, как компания решила разработать гибко конфигурируемое решение, в котором программирование сведено к минимуму, а основную работу делают "аналитики". И тут есть пара подводных камней. Скилсеты хорошего программиста и хорошего аналитика довольно сильно различаются, и в плане грамотной декомпозиции и переиспользования частей кода, ой, т. е. конфигурации, аналитики показывали себя не очень хорошо, примерно на уровне джуниор программистов. Обходясь при этом сильно дороже. Квалифицированные программисты имели тенденцию надолго не задерживаться, т. к. им скучно заниматься "конфигурированием", они хотят программировать. А аналитики постепенно становились "программистами на платформе X" - а такая квалификация не сильно ценится где-то за пределами компании X. Да и на рынке программистов на своей платформе ты не найдешь (если ты не SAP или 1С, условно), а значит, новичков надо обучать с нуля.
Не утверждаю, что описанные проблемы возникают в каждом случае, но мне кажется, они довольно типичны. Есть даже устоявшийся термин Inner Platform Effect.
SergeIndex Автор
05.09.2021 18:36То, что вы пишете, справедливо для Low code платформ. Выше в обсуждении был вопрос, чем наш подход от них отличается, вот ответ: https://habr.com/ru/post/576304/#comment_23447646
Про квалификацию добавлю, что специальность "онтолог" набирает популярность. Поскольку методы онтологического моделирования описаны спецификациями W3C и позволяют моделировать что угодно, скиллы обучившегося им человека не привязан к платформе, на которой он работает в компании X.
vagon333
04.09.2021 23:41+1Есть опыт в построении и многолетнем использовании такой системы.
Вкратце на английском, чтоб не запутать в терминологии:
- Data storage: data-driven definition for storage and storage access.
- Backend: data-driven schema, constraints, relations, business logic.
- Frontend: data-driven library of UI controls
- Frontend: data-driven UI to manage the control properties
- Frontend: data-driven support for multiple web and mobile applications
Вобщем, кодовая база минимальна. Остальное - metadata.В итоге:
- с 2017 несколько коммерческих продуктов - полет нормальный
- планов перехода на классическую разработку нет
- доработка существующих или разработка новых продуктов сократилась на порядокДетали:
Pros:надежность выше по сравнению с классической разработкой
нет необходимости "протаскивать" изменение схемы по слоям
по сравнению с ORM (EF и NHibernate), работает шустрее и легче переносится в облако. ORM тенденция генерить массу мелких запросов, которые в облаке при небольшой latency между серверами вызывает серьезные задержки.
хранение в метаданных: схемы приложений (ERD), диаграмм процессов (BPMN), UI, бизнес логики.
мощная система управления правами доступа
идеально для стартапов: позволяет создать MVP и продолжать до полноценного продукта, без переделок.
extremely high "time to market"
Cons:
Порог вхождения выше
Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).
-
Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь
SergeIndex Автор
05.09.2021 08:28нет необходимости "протаскивать" изменение схемы по слоям
Это - один из главных моментов, но и в остальном полностью согласен.
Change tracking усложнен т.к. классические VCS (Git) построены на сравнении text data, а в системе сравнивать нужно транзакции (record changes).
Да, добавляется проблема ведения версий модели и - при существенном изменении модели - деплоя модели одновременно с кодом, который готов с ней работать. Особенно печально, если на продуктиве нельзя заменить модель целиком - например потому, что заказчик со своей стороны сам в ней что-то редактирует. Мы к таким операциям приспособились с помощью а) механизма версионирования модели в платформе, б) механизма подписки на изменения в модели - с его помощью можно на сервере разработки формировать лог транзакций, которые меняют модель, и затем применять их на тесте и проде.
Сложно найти разработчиков, на иную модель разработки т.к. переиспользование знаний нулевое и в резюме не напишешь
Мы при найме разработчиков даже ничего не говорим про иную модель) Уже в процессе работы плавно вводим в курс дела.
nin-jin
05.09.2021 11:20Можно хранить модели в crdt виде, тогда можно будет мёржить их без конфликта, вычислять дельты и даже находу менять типы. Гляньте проект $hyoo_crowd на эту тему.
SergeIndex Автор
05.09.2021 08:31По просьбе одного из читателей, с кем переписывались в личке, привожу пример алгоритма, работающего с моделью.
Пусть в онтологии описаны некие структурные подразделения или организации, сотрудникам которых доступны некоторые операции с объектами определенных классов (типов) в зависимости от их функциональной роли. В онтологии формализованы правила, каждое из которых представляет собой связку объектов:
[ организация, роль пользователей, класс модели предметной области, операция ]
например:
[ Департамент маркетинга, Ведущий специалист, Клиент, Просмотр ]
[ Департамент маркетинга, Ведущий специалист, Потенциальный клиент, Создание ]
Организационные единицы и классы модели предметной области образуют иерархии, т.е. Департамент маркетинга может содержать вложенные орг. единицы (отделы, группы и т.д.), класс Клиент также может содержать подклассы, например Потенциальный клиент/Активный клиент или Юр. лицо/Физ. лицо.
Пусть пользователь работает со списком клиентов. Системе нужно определить,какие операции он сможет выполнить с каждым из них. Алгоритм будет таким:
1) Построить список всех родителей той орг. единицы, к которой относится пользователь (пройти вверх по иерархии орг. единиц)
2) Построить список всех родителей того класса(-ов), к которому относится проверяемый объект
3) Найти правила, в которых "организация" равна одной из полученных орг. единиц, "класс" равен одному из полученных классов, "роль" равна роли текущего пользователя. Ранжировать правила по степени спецфичности, т.е. правила, определенные для потомков, переопределяют правила, определенные для родителей.
4) По полученному списку правил составить список операций, доступных пользователю.
Подобным образом формализуются и другие правила: перехода процесса между стадиями, видимости свойств объекта разным пользователям, формирования карточки объекта и т.д. При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
lair
05.09.2021 10:22-1При появлении в системе нового класса объектов достаточно создать для него набор правил, и система сможет его обрабатывать.
Мне вот интересно, чем это отличается от "при появлении в системе нового класса объектов достаточно создать для него методов/процедур/обработчиков, и система сможет его обрабатывать"?
SergeIndex Автор
05.09.2021 10:44Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели. В нашем случае они физически лежат в той же графовой базе (или в других базах, которые на уровне API выглядят как графовая, но это уже детали). Лежат в виде точно таких же триплетов (элементарная единица информации в графовой СУБД), что и описание структуры данных, и сами данные. Технологически все это вместе образует единое и неразрывное структурированное описание знаний об автоматизируемой предметной области, корпоративный граф знаний (см. Enterprise knowledge graph).
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные (по крайней мере в части справочных данных, с оперативными данными работают пользователи через свои фронт-энды, но и аналитикам они доступны через универсальные инструменты).
lair
05.09.2021 10:47-1Все тем же: методы/процедуры/обработчики создаются в программном коде, а правила создаются в онтологической модели.
Программный код — это программная модель процесса. Вся разница в форме записи?
Эта технологическая неразрывность означает, что описание правил редактируется теми же инструментами и людьми, что и описание структуры данных, и сами данные
Это выглядит удобно, но с одной оговоркой: если для описания правил доступен весь тот же инструментарий, который доступен "обычному программисту" для "традиционного языка программирования" — контроль версий, статический анализ, рефакторинг и так далее.
Dair_Targ
05.09.2021 11:16+1Как происходит версионироварие и совместная работа над онтологической моделью? Как разделяются условные staging и production версии?
SergeIndex Автор
05.09.2021 18:27Модель - это набор триплетов в графовой базе данных. Есть транзакции, которые изменяют состояние этой базы. Как и в обычной базе, транзакции можно записать в журнал и получить возможность "бегать" вперед-назад по состояниям базы. Мы с графом работаем не напрямую, а через платформу, которая обеспечивает такую возможность (получить состояние модели на любой момент времени).
Чтобы привести прод в состояние, в котором находится staging, надо применить на нем некий набор транзакций. У нас этот набор формируется автоматически с помощью механизма распространения изменений по подписке через менеджер очередей. То есть в условной очереди Kafka или RabbitMQ копится набор пакетов с транзакциями, и в нужный момент мы перекидываем их в другую очередь, откуда их заберет система на проде и обновит свою модель до очередного состояния.
Совместная работа с моделью происходит через веб-приложение, редактор онтологий. Редактор тоже работает с графом через платформу, соответственно все выполняемые с его помощью действия попадают в журнал транзакций.
nin-jin
05.09.2021 19:08А пощупать этот редактор можно как-нибудь?
Возможно так же будет интересен $hyoo_rdf - браузер по rdf. Что о нём думаете?
SergeIndex Автор
05.09.2021 19:12Не знаю какая тут политика по рекламе в комментариях, поэтому ответил в личку. $hyoo_rdf не видел, посмотрю, спасибо.
Axetic
06.09.2021 10:15Согласен с автором. Давно назрело четкое разделение данных на отдельные слои программного уровня и пользовательских данных. Концепция заложенная в 1981 года Э. Ф. Коддом реляционных БД на основе которой был сформированы стандарты SQL, хорошо подходит для организации данных внутри базы данных и ПО, но не работы с бизнес-данными.
В SAP S/4 HANA и других ERP мы не встретим объекты типа яблочки или машинок, о которых рассказывают в учебниках. Но даже те объекты, которые там есть задают жесткость процессов, которые регулярно приходится «натягивать» на бизнес.
В части комментариев правильно задаются вопросом, зачем для аналитиков отдельный слой со своей онтологией и метамоделью. Ответ в том, что им требуются другие правила и инструменты работы с данными. Пользовательские данные могут содержать ошибки консистентности, выбросы и многое другое. С ними нужно работать и стандарты SQL плохо для этого подходят со своей жесткостью. Что не мыслимо для БД и приведет к краху приложения, может и должно сохраняться в пользовательских данных.
Второе. Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны. По моему мнению, в хороших системах класса АСУ Предприятия (ERP и др.) должна быть возможность изменения модели без изменения функциональности ПО. И не только модели, но и данных после таких изменений.
Существующие технологии пока только определяются и формируются (понятно это не ORM :). В любом случае это тренд, пусть и не все его принимают.
P.S. Из интересных фактов. В amazon и ряде других буржуйских компаний, на балансе предприятия ставят бизнес-данные отдельно от ПО.
lair
06.09.2021 10:51-1Как правильно замечено, управление структурой пользовательских данных занимается бизнес. Точнее, управленец с помощью аналитиков. Модель управления регулярно меняется, и программисты столько же в этом понимают, сколько управленец в программирование. Они сами решают какие данные им нужны.
А вы, я так понимаю, считаете, что управленец и аналитики понимают в проектировании структур данных не хуже программиста?
Afigan
Идея хороша, можно было бы уволить всех дорогих программистов и заменить их аналитиками, и бизнесу жилось бы прекрасно. Но существующие подходы существуют не просто так, есть ограничения реального мира, жесткие диски, сеть, процессор, память, в условиях бесконечно быстрой и бесконечно большой памяти, бесконечно быстрого процессора можно было придумать любые абстракции их они бы хорошо работали. Даже с существующим железом для систем где данных не очень много, можно было бы подобное реализовать и похожие решения существуют, где можно задавать через ui сущности, делать для них ограничения, разделять доступ т.п. но:
1. Чем больше данных, тем более мы ограничены реальным миром (железом). Как пример,
в результате в реальном мире где-то данные хранят строками, где-то колонками, кому-то хватает json-а для передачи данных, кто-то экономит каждый бит и придумывает свои форматы.
2. Чем более гибкая система тем она сложнее и требует более сложных навыков для работы, и чем более гибкой мы будем делать систему, тем больше она будет напоминать обычную бд с SQL (который придумали как простой язык для непрограммистов), а работа аналитика работу программиста.
SergeIndex Автор
С ограничениями по железу мы при использовании такого подхода не сталкивались: скажем, ORM или известные "большие платформы" гораздо хуже влияют на производительность.
А в части сложных навыков соглашусь с вами: требования к аналитикам растут, в процессе создания системы приходится гораздо больше думать, чем при привычной разработке. Это ограничение.
Но и подход мы рекомендуем для разработки не всех систем, а только таких, которые работают с очень сложной и изменчивой структурой данных; их создание в любом случае требует больших ресурсов, но при классическом подходе тут есть большие шансы вообще зайти в тупик. Приходилось видеть не одну автоматизированную систему, фактически заброшенную из-за невозможности оперативно вносить в нее требуемые изменения, хотя на разработку были потрачены огромные суммы. В таких случаях построение системы вокруг модели данных однозначно себя оправдывает.