261105_CI-3
Отлично, Дис. Вот третий вариант — иерархическая адресация компонентов с сегментной нумерацией. Каждый уровень — сегмент, и из самого идентификатора видно, где компонент находится.
Вариант 3. Иерархия «Группа → Подгруппа → Компонент → Интерфейс → Функция»
Принцип: идентификатор — это путь по дереву, а не просто номер. E.01.ui.02 читается как «группа E → подгруппа 01 → компонент ui → интерфейс 02».
Обозначение групп
Группа | Название | Назначение |
E | External / Edge | Внешние системы, клиентские интерфейсы, шлюзы |
A | Application | Прикладные сервисы (кастомная бизнес-логика) |
B | Business | Процессы (базовая бизнес-логика) |
C | Core | Сервисы ядра (платформа, реестр, идентичность) |
I | Infrastructure | Инфраструктура (шина, БД, доставка, среды) |
E. External / Edge
E.01. Клиентские интерфейсы (UI) │ ├── E.01.01. portal — Портал станций │ │ ├── E.01.01.01. interface:web-ui │ │ └── E.01.01.02. function:station-switch │ ├── E.01.02. console — Консоль сценариев │ │ ├── E.01.02.01. interface:webcrypto-sign │ │ └── E.01.02.02. function:dice-flow │ ├── E.01.03. scan — Скан/печать паспорта │ │ ├── E.01.03.01. interface:camera-scan │ │ └── E.01.03.02. function:print-passport │ └── E.01.04. contracteum-front — Frontend Контрактиума │ └── E.01.04.01. interface:web-ui │ E.02. Шлюзы (Gateways) │ └── E.02.01. apigw — REST/GraphQL шлюз │ ├── E.02.01.01. interface:rest │ ├── E.02.01.02. interface:graphql │ └── E.02.01.03. function:jwt-rbac │ E.03. CLI и агентные интерфейсы │ ├── E.03.01. didsign │ │ └── E.03.01.01. interface:cli │ ├── E.03.02. agentmanifest │ │ └── E.03.02.01. interface:cli │ ├── E.03.03. agentmcp │ │ ├── E.03.03.01. interface:mcp │ │ └── E.03.03.02. function:init-call │ ├── E.03.04. stand5-flow │ │ └── E.03.04.01. interface:script │ └── E.03.05. ledger-demo │ └── E.03.05.01. interface:cli │ E.04. Внешние системы (External) │ ├── E.04.01. BIMAR │ │ └── E.04.01.01. interface:vc-api │ ├── E.04.02. SCADA DEMO API │ │ └── E.04.02.01. interface:rest │ ├── E.04.03. Yandex Cloud API │ │ └── E.04.03.01. interface:rest │ ├── E.04.04. Внешние PKI/УЦ │ │ └── E.04.04.01. interface:crl-ocsp │ ├── E.04.05. W3C DID registry │ │ └── E.04.05.01. interface:http │ └── E.04.06. Email-шлюз │ └── E.04.06.01. interface:smtp
A. Application (прикладные сервисы)
A.01. Договорный контур │ └── A.01.01. contractengine — Договорный контур │ ├── A.01.01.01. interface:rest │ └── A.01.01.02. function:contract-lifecycle │ A.02. Документы и хранение │ ├── A.02.01. documents-svc │ │ ├── A.02.01.01. interface:rest │ │ ├── A.02.01.02. function:template-render │ │ ├── A.02.01.03. function:hlf-client │ │ └── A.02.01.04. function:passport-sync │ └── A.02.02. storage-svc │ ├── A.02.02.01. interface:rest │ └── A.02.02.02. function:file-store │ A.03. Цифровые паспорта и активы │ └── A.03.01. app-assets (assets-app) │ ├── A.03.01.01. interface:rest │ ├── A.03.01.02. function:passport-crud │ ├── A.03.01.03. function:shipment │ └── A.03.01.04. function:kbo │ A.04. Прикладные процессы │ ├── A.04.01. applications — Заявки │ │ └── A.04.01.01. interface:rest │ ├── A.04.02. registrations — Регистрации │ │ └── A.04.02.01. interface:rest │ ├── A.04.03. verifications — Проверки │ │ ├── A.04.03.01. interface:rest │ │ └── A.04.03.02. function:probe-check-pki │ └── A.04.04. poa — МЧД │ └── A.04.04.01. interface:rest │ A.05. Инфраструктурные прикладные сервисы │ ├── A.05.01. notifications │ │ └── A.05.01.01. interface:rest │ ├── A.05.02. dictionaries │ │ └── A.05.02.01. interface:rest │ └── A.05.03. payments │ └── A.05.03.01. interface:rest
C. Core (сервисы ядра)
C.01. Идентичность и доступ │ ├── C.01.01. auth │ │ ├── C.01.01.01. interface:rest │ │ ├── C.01.01.02. function:ukep-login │ │ └── C.01.01.03. function:token-issue │ ├── C.01.02. organizations │ │ └── C.01.02.01. interface:rest │ └── C.01.03. identity-svc │ ├── C.01.03.01. interface:rest │ └── C.01.03.02. function:person-credential │ C.02. Криптография и PKI │ ├── C.02.01. pki-svc │ │ ├── C.02.01.01. interface:rest │ │ ├── C.02.01.02. function:x509-parse │ │ └── C.02.01.03. function:test-cert-issue │ ├── C.02.02. cspgw-svc │ │ ├── C.02.02.01. interface:gost-sign │ │ └── C.02.02.02. function:hlf-tx-sign │ ├── C.02.03. cspemul-svc │ │ ├── C.02.03.01. interface:cms-sign │ │ └── C.02.03.02. function:cms-verify │ └── C.02.04. sigutils (library) │ ├── C.02.04.01. function:cades │ ├── C.02.04.02. function:pkcs7 │ ├── C.02.04.03. function:xmldsig │ └── C.02.04.04. function:pep │ C.03. DID/VC-реестр │ ├── C.03.01. did-svc │ │ ├── C.03.01.01. interface:rest-8080 │ │ ├── C.03.01.02. interface:grpc-9090 │ │ ├── C.03.01.03. function:did-resolve │ │ ├── C.03.01.04. function:signed-ops │ │ └── C.03.01.05. function:outbox │ ├── C.03.02. vc-svc │ │ ├── C.03.02.01. interface:rest-8081 │ │ ├── C.03.02.02. function:vc-jwt │ │ ├── C.03.02.03. function:revoke │ │ ├── C.03.02.04. function:scan │ │ ├── C.03.02.05. function:custody │ │ └── C.03.02.06. function:agent-mandate │ └── C.03.03. DAPSvc (требует уточнения) │ └── C.03.03.01. interface:tbd │ C.04. Блокчейн-доступ │ ├── C.04.01. blockchain-svc │ │ ├── C.04.01.01. interface:invoke-query │ │ ├── C.04.01.02. function:wallet │ │ └── C.04.01.03. function:client │ ├── C.04.02. blockchain-hlf (adapter) │ │ ├── C.04.02.01. function:postgres-adapter │ │ └── C.04.02.02. function:nats-adapter │ ├── C.04.03. docs-chaincode │ │ ├── C.04.03.01. function:kcont-2249 │ │ └── C.04.03.02. function:docs-collection │ ├── C.04.04. did-registry (chaincode) │ │ └── C.04.04.01. function:did-vc-worldstate │ └── C.04.05. Blockchain Viewer │ ├── C.04.05.01. interface:ledger-api │ └── C.04.05.02. function:ledger-query │ C.05. Сеть HLF │ └── C.05.01. HLF Network │ ├── C.05.01.01. peer0-gazprom │ ├── C.05.01.02. peer0-tmk │ ├── C.05.01.03. orderer │ └── C.05.01.04. channel-org
I. Infrastructure
I.01. Шина и данные │ ├── I.01.01. NATS │ │ └── I.01.01.01. interface:pub-sub │ └── I.01.02. PostgreSQL │ └── I.01.02.01. interface:sql │ I.02. Среды и оркестрация │ ├── I.02.01. ZeptoClaw │ │ ├── I.02.01.01. container:agent-a │ │ ├── I.02.01.02. interface:gateway-3000-8080-9090 │ │ └── I.02.01.03. function:approval-gate │ ├── I.02.02. YandexGPT_to_OpenAI (y2o) │ │ └── I.02.02.01. interface:proxy-8520 │ ├── I.02.03. Docker │ │ └── I.02.03.01. container-runtime │ └── I.02.04. Namespace develop-contracteum4 │ └── I.02.04.01. environment:stand-develop4 │ I.03. Доставка │ └── I.03.01. ArgoCD + GitLab registry │ ├── I.03.01.01. function:gitops-sync │ └── I.03.01.02. function:image-tag
📌 Как это читается
Идентификатор | Читается как |
| External → Шлюзы → apigw → функция jwt-rbac |
| Application → Документы → documents-svc → функция hlf-client |
| Core → DID/VC-реестр → vc-svc → функция custody |
| Core → Блокчейн → docs-chaincode → функция kcont-2249 |
| Infrastructure → Шина и данные → PostgreSQL → интерфейс sql |
Правила сегментации:
1-й сегмент — группа (E/A/C/I). Всегда 1 буква.
2-й сегмент — подгруппа (01, 02…). Двузначный номер.
3-й сегмент — компонент. Двузначный номер.
4-й сегмент — интерфейс/функция. Двузначный номер.
Далее — вложенные функции (если нужно).
🧠 Почему это удобно
Свойство | Как достигается |
Читаемость взаимозависимостей | По префиксу видно, к какой группе относится компонент. |
Управляемость | Каждая группа — зона ответственности (E — фронт/DevOps, A — продуктовая команда, C — платформа, I — инфра). |
Масштабируемость | Новый компонент получает следующий свободный номер в своей подгруппе. |
Трассируемость | Баг |
Связь с эпиками | Эпик F1 «Выпуск VC» ссылается на компоненты: |
Итог: третий вариант — это адресная иерархия, где идентификатор несёт смысл. В отличие от Варианта 1 (слои) и Варианта 2 (потоки), здесь сам код компонента говорит, где он живёт и к какому слою/группе относится. Это ближе всего к тому, что ты просил: группы сервисов + сегментная нумерация интерфейсов и функций внутри каждого.