|
1 | | -# Пример структуры репозитория для описания архитектуры |
| 1 | +# Пример структуры репозитория для описания архитектуры v 2.0 |
2 | 2 |
|
3 | 3 | **Цель примера:** Снизить порог вхождения в DocHub за счет внедрения типовых шаблонов структуры репозитория и меню DocHub для управления корпоративной архитектурой. |
4 | 4 |
|
| 5 | +# Отличия от предыдущей версии |
| 6 | +* Основным отличием от предыдущей версии является то, что в этой версии управление метамоделями выделено в отдельную папку **metamodels** с целью разделения архитектурных данных и структуры метамоделей. Планируется, что будет разработано два пайплайна. В случае изменения архитектурных данных, эти данные сразу будет ехать на прод, предварительно проверяя наличие ошибок в валидаторе. В случае изменения метамодели, будет проводиться ревью изменений, а только потом специально обученный человек завезет изменения в прод. |
| 7 | +* Второе отличие заключается в том, что пример стал более функциональным. В него был внесено множество реально работающих алгоритмов. |
| 8 | + |
5 | 9 | # Суть примера |
6 | 10 | Существует множество различных подходов к описанию архитектуры компании. В нашей компании была выбрана методология TOGAF. При этом мы не пытаемся внедрить классическую методологию TOGAF, мы используем комбинированный подход, выбирая только те инструменты, которые закрывают наиболее критичные риски компании. |
7 | 11 |
|
|
18 | 22 |
|
19 | 23 | ## Файловая структура примера |
20 | 24 | * **application_arch** - в этой папке хранятся все данные, связанные с прикладной архитектурой, кроме контекстов. Контексты мы вынесли в отдельную папку artefacts. Детально про artefacts можно почитать ниже. |
21 | | - * **systems** - в этой папке хранятся данные по системам. Каждую систему мы описываем в своём файле и имя файла всегда соответствует имени системы. Идентификатор системы в общем случае представляет из себя доменное имя в виде: `<имя компании>.<имя бизнес-юнита>.<имя системы>`. Если вдруг у системы нет своего репозитория, то в этом файле мы также описываем runtime компоненты этой системы, что позволяет хранить всю информацию по системе в одном месте. |
| 25 | + * **reports** - в этой папке хранятся различные отчеты по системам. |
| 26 | + * **systems** - в этой папке хранятся данные по системам. Каждую систему мы описываем в своём файле и имя файла всегда соответствует имени системы. Идентификатор системы в общем случае представляет из себя доменное имя в виде: `<имя компании>.<имя бизнес-юнита>.<имя системы>`. Если вдруг у системы нет своего репозитория, то в этом файле мы также описываем runtime компоненты этой системы, что позволяет хранить всю информацию по системе в одном месте. |
22 | 27 | * **artefacts** - в этой папке мы храним все артефакты по системам, например контексты мы храним в такой структуре: `./artefacts/<имя бизнес-юнита>/<имя контекста>`. Также здесь мы храним различные схемы по системам. |
| 28 | + * **common** - в этой папке хранится общий контекст ГК Болото. |
| 29 | + * **frog_paradise** - в этой папке хранится контекст БЮ Лягушачий рай. |
23 | 30 | * **business_arch** - в этой папке хранятся все данные, связанные с бизнес-архитектурой. На текущий момент мы не ведем в DocHub бизнес-архитектуру. Возможно, суда будем класть архитектурные скетчи, когда Рома закончит встраивать в DocHub https://excalidraw.com/ |
24 | 31 | * **dictionaries** - вспомогательная папка для хранения справочной информации. Например, при заполнении системы встал вопрос по её статусе, и чтобы не дублировать каждый раз всю информацию по статусу мы сделали справочник статусов и в системе используем только идентификатор, а если нам нужна полная информация, то получаем её при помощи функции $lookup внутри запроса. |
| 32 | +* **documentation** - в этой папке хранится общая документация. Мы пытались её размещать в различных папках, но в конце концов приняли решение сделать для неё отдельное место. |
| 33 | + * **glossary** - в этой папке хранится глоссарий ГК Болото. |
| 34 | + * **useful_links** - в этой папке хранятся полезные линки на внешние ресурсы. Это может быть Confluence, различные обучающие видео на YouTube и т.д. |
| 35 | + * **images** - в этой папке хранятся картинки для документации. |
25 | 36 | * **enterprise_arch** - это папка корпоративных архитекторов, сюда мы помещаем всю информацию, которая связана с развитием архитектуры в компании. |
26 | | - * **adr** - в этой папке мы храним реестр архитектурных решений |
| 37 | + * **adr** - в этой папке хранится реестр архитектурных решений |
27 | 38 | * **processes** - в этой папке мы храним документацию по различным архитектурным процессам |
28 | | - * **tools** - в этой папке мы храним документацию по инструментам архитектуры |
29 | | - * **dochub** - в этой папке мы храним документацию по DocHub |
30 | | - * **welcome** - в этой папке мы храним документацию, которая выводится при открытии DocHub (welcome page) |
| 39 | + * **tools** - в этой папке хранится документация по инструментам архитектуры |
| 40 | + * **dochub** - в этой папке хранится документация по DocHub |
| 41 | + * **welcome** - в этой папке хранится документация, которая выводится при открытии DocHub (welcome page) |
31 | 42 | * **images** - картинки для настоящей документации |
32 | 43 | * **information_arch** - в этой папке хранятся все данные, связанные с информационной архитектурой. На текущий момент мы в начале пути и сделали пока только прототип по управлению бизнес-сущностями на логическом уровне. |
33 | | -* **settings** - здесь мы храним всякие настройки |
34 | | - * **datasets** - здесь у нас общие запросы |
35 | | - * **jsonata** - здесь у нас общие функции. Пример использования можно посмотреть [здесь](https://github.com/rpiontik/DocHubExamples/blob/main/src/jsonata_query_examples/jsonata_query_example.md). |
36 | | - * **validators** - здесь мы описываем валидаторы, которые нужно выводить в общее меню проблем. Пример использования можно посмотреть [здесь](https://github.com/rpiontik/DocHubExamples/tree/main/src/validator_example) |
| 44 | + * **business_entities** - в этой папке хранятся данные по бизнес-сущностям. Сама модель переехала в папку metamodels. |
| 45 | +* **metamodels** - в этой папке хранятся все метамодели, а также дополнительные наборы данных и инструментов необходимых для разработки метaмоделей и их валидации. |
| 46 | + * **custom** - в этой папке хранится описание всех пользовательских матамоделей. |
| 47 | + * **business_entities** - в этой папке хранится описание модели по управлению бизнес-сущностями на логическом уровне. |
| 48 | + * **dictionaries** - в этой папке хранится матамодель описывающая структуру справочников. |
| 49 | + * **dochub_menu** - в этой папке хранится матамодель описывающая целевую структуру меню. |
| 50 | + * **datasets** - в этой папке хранятся все общие запросы (datasets). |
| 51 | + * **default** - в этой папке хранятся все инструменты для расширения дефолтных метамоделей DocHub. |
| 52 | + * **jsonata** - в этой папке хранятся общие функции. Пример использования можно посмотреть [здесь](https://github.com/rpiontik/DocHubExamples/blob/main/src/jsonata_query_examples/jsonata_query_example.md). |
| 53 | + * **validators** - здесь мы описываем валидаторы, которые нужно выводить в общее меню проблем. В самой папке есть два вида примеров, это валидация через schema и валидация через проверку заполнения конкретных параметров. Пример использования для schema можно посмотреть [здесь](https://github.com/rpiontik/DocHubExamples/tree/main/src/validator_example). |
37 | 54 | * **standards** - это одна из ключевых папок, где мы храним архитектурные принципы и стандарты, которые обязательны к выполнению всеми командами |
38 | 55 | * **arch_principles** - здесь у нас описаны архитектурные принципы и принципы информационной безопасности |
39 | 56 | * **it_platforms** - здесь мы храним архитектурные стандарты по платформам, а также принятые нотации по кодированию |
|
0 commit comments