Когда мы начинаем говорить о том, что же такое ODANT, часто возникают сложности в понимании основных концепций. Вот о том, где такие проблемы появляются, что с ними делать, и как начать думать в терминах ODANT — ниже.
Компонентный подход
![2 2](https://csc.odant.org/wp-content/uploads/elementor/thumbs/2-nxzwqgxojgp0elpqitmn60ajfzxgquje9uwszzhkd8.png)
Это не о программных компонентах, не о библиотеках. Не о монолитных приложениях и микросервисах. Речь о компонентном подходе к информации. Компонент в ODANT — это класс. Или объект. Или модуль, который по сути тоже является классом. Каждый класс — это уникальная информационная сущность с собственным глобальным идентификатором, по которому к нему можно обращаться. При использовании какого-то ранее созданного класса в своей системе, мы создаем его наследника. Он будет обладать всеми свойствами родителя, но это уже другой класс со своим идентификатором.
![2 2](https://csc.odant.org/wp-content/uploads/elementor/thumbs/2-1-nxzyzyk0990s305xrdvzex0i321gg2a73i2jx0m388.png)
Если совсем на пальцах — для создания решения автоматизации нам нужно отнаследовать несколько классов в свою систему и поработать над их связью между собой. Галочку, например, поставить, означающую использование в одном классе сервисов, которые принес с собой другой.
Распределенная архитектура
Это не про кластеры, шардинг или распределенную файловую систему. Технология ODANT не подразумевает использования одной большой БД, которую при масштабировании приходится сохранять виртуально единой, а фактически на более низком уровне разбрасывать по нескольким серверам.
![3 3](https://csc.odant.org/wp-content/uploads/elementor/thumbs/3-ny000zf7a3v646m1onb1016neo72po4ds7s2m1n7oy.png)
Информация распределена по разным серверам логически. Один набор классов — на одном, другой — на другом. Можно представить это как таблицы одной реляционной БД, распределенные по серверам, но аналогия не совсем верная. Ближе к истине — если подумать о таблицах, все данные для работы с которыми в них уже лежат, и по связям с другими таблицами ходить не надо.
Иерархическая модель
Вся магия в наследовании. Создаем одну БД в головной организации. Наследуем ее в системы филиалов. Сейчас сверху и снизу конфигурация абсолютно одинаковая. Дальше в филиале мы можем модифицировать систему необходимым образом. Вот, например, нужно на месте подключить базу 1С. Для этого настраиваются коннекторы, а затем — сопоставления. То есть, в локальной системе будет, грубо, две таблицы. Одна — глобальная, унаследованная сверху. В ней поля «Адрес», «Телефон» и «ФИО». Другая таблица в терминах существующей ИС, там «Адр.», «Тел.», «Фамилия», «Имя» и «Отчество». Импорт настроен таким образом, что данные во второй таблице автоматически обновляются при изменениях в 1С.
![4 4](https://csc.odant.org/wp-content/uploads/elementor/thumbs/4-ny1jpky6lpujg8lf4dz1o7y7kx588wdq4lcee7hb2g.png)
В локальной системе осталось настроить сопоставление полей. В поле «Адрес» первой таблицы будет копироваться информация из «Адр.» второй и так далее. И теперь в головной организации можно запрашивать отчеты из любого филиала или их группы, ведь модель данных в интегрирующей системе едина.
Реактивные вычисления
![5 5](https://csc.odant.org/wp-content/uploads/elementor/thumbs/5-ny1jz8qguf2mryk8pkb0as6rdhj1cwqeseq1yl5mvc.png)
В предыдущем примере интересный момент был. В одной структуре «ФИО» — одно поле, в другой — три. Проблема решается просто, для получения ФИО пишется XQuery-запрос, выдающий конкатенацию строк с фамилией, именем и отчеством. А исполняется запрос по созданию или изменению данных во второй структуре. Всего в ODANT предусмотрено шесть триггеров, срабатывающих по созданию, изменению или удалению записей; до или после указанного действия. Плюс триггеры, срабатывающие по маске времени.
Агрегация, наследование и гибридный режим
![6 6](https://csc.odant.org/wp-content/uploads/elementor/thumbs/6-ny1o7cy9awuvyz8mlzsvzcaxjbabt93o9xnk5jiir6.png)
![7 7](https://csc.odant.org/wp-content/uploads/elementor/thumbs/7-ny1omql74bwrxawft5459ylff9hiqz5kq1wjtipmx6.png)
Чрезвычайно важная вещь для понимания того, как вообще работать с данными в ODANT. Допустим, в базе головной организации есть класс «Контрагенты». Обращаясь к этому классу, мы видим все данные в классах «Контрагенты» организаций ниже по иерархии. Это режим агрегации. Второй режим — наследование, здесь это не о структуре, не о наследовании классов, а о наследовании объектов, то есть — данных. Данные в классе «Должностные инструкции», находящиеся в головной организации, будут видны при обращении к классу с таким же идентификатором в дочерних.
![8 8](https://csc.odant.org/wp-content/uploads/elementor/thumbs/8-ny1p1vrl88n2z4wjdorrg50ryquerf9w50a6609aoa.png)
![9 9](https://csc.odant.org/wp-content/uploads/elementor/thumbs/9-ny1pgk0vx4q87zl7p143dfpttaioxbj1hmx1vii1mg.png)
Гибридный режим — это объединение агрегации и наследования. Где бы что ни лежало, оно будет видно из любого класса в иерархии с соответствующим названием. Чтобы было интереснее, добавим к этому функционалу локальное переопределение объектов. Есть в одной из организаций в иерархии контрагент «ООО “Рога и копыта”». В гибридном режиме он виден отовсюду. Но тут выясняется, что другая организация уже работает с ним, только записан он в местной ИС как «Рога и копыта, ООО». Переопределим объект таким образом, чтобы в локальной версии в нем название контрагента было «Рога и копыта, ООО». Теперь в этой организации контрагент называется по-старому, но остальные его видят с общим наименованием.
Подытожим
В терминах ODANT, компонентный подход — это использование функционально законченных информационных сущностей. Распределенная архитектура — это не разделение виртуально целой БД по кластерам серверов, а распределение данных по логике их использования. Иерархическая модель — наследование структуры, позволяющей получить одинаковую конфигурацию на всех уровнях (а значит, обращаться к любой системе в общих терминах), затем локально расширяемую для интеграции с местными информационными системами. Принципиальными в понимании основ работы с данными в ODANT являются концепции режимов «агрегация», «наследование», «агрегация + наследование» и реактивных вычислений — пересчета данных в объектах по срабатыванию определенных триггеров.