Реєстр договорів починається з картки документа, контрагента й кількох вкладень. Через пів року в ньому вже є редакції договорів, права доступу за підрозділами та інтеграція з обліковою системою. Потім бізнес просить розподіляти суми між бюджетними статтями й відкрити контрагентам доступ до частини документів. На цьому етапі архітектуру оцінюють за тим, скільки шарів системи зачіпає кожна зміна і як команда переносить її на дані, з якими вже працюють користувачі.
UnityBase — корпоративна low-code платформа з власним серверним середовищем JavaScript. Її основа — модель предметної області, яку платформа використовує для роботи з даними, генерації API й адміністративних інтерфейсів. Розробники описують типову структуру декларативно, а правила конкретного продукту реалізують у коді. Такий підхід підходить для реєстрів, систем документообігу, корпоративних кабінетів і галузевих застосунків із пов’язаними даними та складними правами доступу. Архітектура UnityBase
1. Одна модель для кількох шарів застосунку
У UnityBase сутності, атрибути та зв’язки описують у файлах метаданих .meta. Цей опис використовують ORM, інструменти генерації схеми БД, API й адміністративний інтерфейс. Наприклад, договір має суму, статус і посилання на контрагента. У запитах UBQL розробник працює із сутністю договору та її атрибутами, а платформа формує запит до бази даних. Документація UnityBase · Модель предметної області та UBQL
Уявімо нову вимогу. Один договір тепер може фінансуватися з кількох бюджетних статей. Команда додає сутність «Розподіл бюджету» зі зв’язками на договір і бюджетну статтю та полем для суми. Платформні інструменти допомагають підготувати схему й типові операції над новою сутністю. У прикладному коді команда визначає, хто може змінювати розподіл, як перевіряти суми та що робити, якщо бюджетну статтю закрили після погодження договору.
Перевага для розробника: менше окремих описів тієї самої структури. Новий зв’язок з’являється в моделі, на яку вже спираються інструменти платформи. Час команди йде на поведінку продукту й перевірку того, як зміна вплине на робочий процес.
2. Серверний JavaScript для правил, які визначають продукт
UnityBase має HTTP(S)-сервер із вбудованим рушієм JavaScript SpiderMonkey. Розробник може додавати серверні методи до сутностей і підключати зовнішні сервіси через API. У навчальному проєкті UnityBase є приклади власного серверного методу, обміну із зовнішнім API та створення окремого клієнтського інтерфейсу. Огляд серверної архітектури · Навчальний проєкт UnityBase
У реєстрі договорів стандартний адміністративний інтерфейс можна використати для довідників контрагентів і бюджетних статей. Для фінансиста команда може створити окремий екран, де видно договір, залишки бюджету та розподіл сум. Серверний метод перевіряє розподіл і зберігає його. Інтеграція з обліковою системою має власні правила щодо повторних запитів і помилок обміну.
Перевага для розробника: готові механізми закривають типові операції, а власний код команда пише там, де від нього залежить поведінка системи. Саме так виглядає low-code у розробці корпоративного продукту.
3. Права доступу на рівні операцій і записів
У корпоративному реєстрі юрист бачить договори свого підрозділу, керівник напряму — кількох підрозділів, а контрагент — документи, які йому передали. У кожної ролі також свій набір дозволених дій. Наприклад, можливість прочитати договір і можливість змінити його статус перевіряються окремо.
UnityBase дає механізми контролю доступу до методів сутностей і Row-Level Security, або RLS, для серверного обмеження видимості записів. RLS додає умови на сервері, коли застосунок працює з відповідною сутністю. Це дає змогу застосовувати правила доступу до даних незалежно від того, з якої форми надійшов запит. Для власних методів та інтеграцій команда визначає й тестує, як ці правила застосовуються на кожному шляху доступу. Документація платформи також описує аудит та історію змін даних. Row-Level Security в UnityBase · Навчальні матеріали про історію даних та аудит
Юрист, КерівникАгросервісЮридичний120 000 ₴
КерівникЛогістик-ЗахідЗакупівлі48 500 ₴
КонтрагентЦифрові системиФінансовий230 000 ₴
КерівникАгросервісЗакупівлі15 000 ₴
Юрист, Керівник, КонтрагентЦифрові системиЮридичний64 000 ₴
Перевага для розробника: новий інтерфейс не потребує нової системи прав. Додаючи кабінет контрагента, команда використовує ту саму модель договорів і серверні механізми доступу. Окремо вона проєктує, які записи та вкладення бачить контрагент і які дії може виконати.
4. Міграції — частина розвитку застосунку
Після запуску зміна моделі зачіпає історичні дані. Якщо раніше договір мав одну бюджетну статтю, а тепер має кілька розподілів, нової таблиці недостатньо. Потрібно перенести попередні значення, визначити поведінку для договорів із неповними даними й перевірити, чи зможуть суміжні системи працювати під час переходу.
Для таких змін UnityBase документує ubcli generateDDL для структури БД і ubcli migrate для виконання міграцій, зокрема власних сценаріїв на JavaScript або SQL. Генерація DDL допомагає привести схему до метаданих. Логіку перетворення наявних записів визначає розробник. Наприклад, документація окремо показує, чому при перейменуванні сутності може знадобитися явний крок міграції. Життєвий цикл застосунку та міграції UnityBase
Для нашого реєстру критерій приймання конкретний. Після переходу сума кожного чинного договору має збігатися із сумою його бюджетних розподілів, а доступ до договору має відповідати попереднім правилам або явно затвердженим змінам.
Перевага для розробника: зміну моделі, міграцію даних і нову прикладну поведінку можна готувати в межах одного релізу.
5. Повторне використання моделі в нових інтерфейсах
Команда може додати кабінет контрагента до внутрішнього реєстру й повторно використати сутності та серверні методи. Для кожного інтерфейсу команда проєктує свій робочий сценарій і перевіряє правила доступу відповідної аудиторії.
UnityBase на практиці
Megapolis.DocNet — продукт для документообігу, який InBase і Softline розробляють на платформній основі. За кейсом InBase, в агрохолдингу «Астарта» система охопила 37 структурних підрозділів і близько 2 000 користувачів, які створювали 1 000–1 200 документів на день. Нові процеси спочатку запускали в одному підрозділі, допрацьовували за результатами роботи, а потім поширювали далі. Портфель продуктів InBase · Повний кейс Астарти
Для розробника в цьому кейсі цікава послідовність. Продукт має підтримувати різні процеси в межах однієї організації, а команда впровадження — поступово уточнювати їх разом із користувачами.
Перевага для розробника: прикладні правила та інтеграції можна додавати в міру появи реальних вимог, а не проєктувати все наперед.
Як інтегрувати ШІ-помічника
У реєстрі договорів фінансисту потрібно прочитати технічне завдання й визначити, до яких бюджетних статей належать описані витрати. Помічник може запропонувати категорії та показати, на яких пунктах ґрунтується пропозиція. Прикладний код перевіряє суми, статуси статей і ліміти. Фінансист обирає й підтверджує розподіл.
У такій архітектурі серверний модуль відбирає документи й вкладення, доступні користувачеві та дозволені для обробки моделлю. Він викликає модель через обмежений інтерфейс і журналює пропозицію та рішення користувача. Для реалізації цих перевірок команда може використати механізми доступу, серверні методи й аудит UnityBase. Фахівець також може виконати перевірку вручну. Керований штучний інтелект у корпоративних системах
Як оцінити UnityBase на власному проєкті
Побудуйте невеликий, але повний сценарій:
- Візьміть договір, контрагента й підрозділ.
- Налаштуйте дві ролі з різною видимістю записів.
- Додайте один серверний метод і передайте результат у тестову облікову систему.
- Змініть вимогу: додайте розподіл бюджету й перенесіть уже створені договори.
- Перевірте, як зміна позначилася на API, доступі та інтерфейсі.
- Підключіть ШІ-помічника через API від імені однієї з ролей. Перевірте, що він бачить лише її записи, а його пропозиції проходять ті самі серверні перевірки.
Під час оцінки зафіксуйте, які частини вдалося отримати з моделі, який код команда написала і що довелося змінити у другій ітерації. Редакцію та СУБД звірте з офіційною матрицею для вашого сценарію. UnityBase публікує OpenUB під Apache License 2.0 та комерційні редакції Enterprise і Defence. Матриця редакцій UnityBase · Стартовий проєкт для розробників
Для команди, яка обирає платформу у 2027 році, саме друга ітерація дасть відповідь на головне питання. Наскільки легко додати нову вимогу до системи, де вже є дані, права доступу та користувачі? У UnityBase є конкретні механізми, щоб перевірити це на своєму коді.