Онтологический справочник типов компонентов

Документ: Регламент классификации программных компонентов КТМ Версия: 1.0 (драфт)
Дата: 5 ноября 2026
Назначение: Единая терминология для реестра компонентов (CI), архитектурных решений (ADR) и проектной документации.
Область применения: Обязателен для использования в описаниях компонентов, ADR, спецификациях и баг-репортах.

предметный указатель

Тип компонента	Краткое описание
1.1. Функциональный сервис	Компонент, обеспечивающий долгоживущий процесс с бизнес-значимостью
1.2. Инфраструктурный сервис	Обслуживает функциональные сервисы, самостоятельной бизнес-ценности не несёт
1.3. Шлюз	Единая точка входа: маршрутизация, аутентификация, авторизация
1.4. Инструмент	CLI или скрипт для разовых и административных операций
1.5. Библиотека	Переиспользуемый код, подключаемый при сборке
1.6. Чейнкод	Логика чтения и записи состояния в HLF
1.7. Внешняя система	Система вне контура проекта, с которой идёт обмен
2.1. Интерфейс	Точка входа и контракт взаимодействия
2.2. Функция	Именованное поведение внутри компонента
2.3. Сущность	Структура данных с идентичностью и жизненным циклом
2.4. Репозиторий (адаптер)	Абстракция доступа к хранилищу или внешней системе

1. Типы компонентов по роли в системе

Классификация отражает назначение компонента в архитектуре и его отношение к бизнес-ценности системы.

1.1. Функциональный сервис (Core / Business / Application Service)

Поле	Значение
Термин	Функциональный сервис
Синонимы	Core-сервис, бизнес-сервис (domain), прикладной сервис
Пояснение	Долгоживущий процесс, реализующий бизнес-логику предметной области. Несёт самостоятельную ценность для пользователя или другого сервиса. Владеет своими данными и правилами их изменения.
Признаки	Имеет собственный домен; содержит бизнес-правила; предоставляет API (REST/gRPC); может хранить состояние.
Пример	`A.assets` — управление цифровыми паспортами; `C.vc` — выпуск и верификация VC; `C.did` — разрешение DID.

Примечание: Прикладной сервис (Application Service) как правило, не имеет собственного домена (rules & database), использует другие сервисы как поставщиков контента, маршрутизирует потоки в соответствии с настройками.

1.2. Инфраструктурный сервис (Support Service)

Поле	Значение
Термин	Инфраструктурный сервис
Синонимы	Support-сервис, вспомогательный сервис
Пояснение	Долгоживущий процесс, обеспечивающий работу функциональных сервисов. Не несёт самостоятельной бизнес-ценности, но без него система не функционирует.
Признаки	Обслуживает другие сервисы; не имеет пользовательского API; часто является общим для нескольких доменов.
Пример	`C.auth` — аутентификация; `I.NATS` — шина сообщений; `I.PostgreSQL` — хранилище.

1.3. Шлюз (Gateway)

Поле	Значение
Термин	Шлюз
Синонимы	API Gateway, Edge-сервис
Пояснение	Компонент, принимающий внешние запросы и маршрутизирующий их во внутренние сервисы. Выполняет сквозные функции: аутентификацию, авторизацию, rate limiting, трансляцию протоколов.
Признаки	Единая точка входа; не содержит бизнес-логики; знает маршруты, но не правила домена.
Пример	`E.apigw` — REST/GraphQL-шлюз с JWT + RBAC.

1.4. Инструмент (CLI / Tool)

Поле	Значение
Термин	Инструмент
Синонимы	CLI-утилита, скрипт, консольная утилита
Пояснение	Исполняемый артефакт, запускаемый вручную или из скрипта для выполнения разовых или административных операций. Не является долгоживущим процессом.
Признаки	Имеет точку входа (main); завершается после выполнения; не предоставляет сетевого API.
Пример	`E.didsign` — подпись DID-операций; `E.agentmanifest` — сборка манифеста агента; `E.ledger-demo` — проверка записи в реестре.

1.5. Библиотека (Library)

Поле	Значение
Термин	Библиотека
Синонимы	Общая библиотека, shared lib
Пояснение	Переиспользуемый код, подключаемый к другим компонентам на этапе сборки. Не запускается самостоятельно.
Признаки	Не имеет точки входа; распространяется как зависимость; версионируется отдельно.
Пример	`C.sigutils` — реализации подписей CAdES, PKCS#7, XMLDSig.

1.6. Чейнкод (Chaincode)

Поле	Значение
Термин	Чейнкод
Синонимы	Смарт-контракт
Пояснение	Компонент, исполняемый в среде распределённого реестра (HLF). Реализует логику записи и чтения состояния в блокчейне.
Признаки	Развёртывается в канал HLF; имеет детерминированное исполнение; не имеет собственного сетевого API.
Пример	`C.docs-chaincode` — документы KCONT-2249; `C.did-registry` — DID/VC в world state.

1.7. Внешняя система (External System)

Поле	Значение
Термин	Внешняя система
Синонимы	Внешняя зависимость
Пояснение	Компонент, не входящий в контур системы, но с которым происходит обмен данными. Не управляется командой проекта.
Признаки	Имеет собственный API; недоступен для изменения; влияет на доступность системы.
Пример	`E.BIMAR` — система изготовителя; `E.SCADA` — демо-API АСУТП; `E.PKI` — внешние УЦ.

2. Типы компонентов по внутренней структуре (слои)

Классификация отражает внутреннее устройство компонента и его место в архитектуре программного средства. Соответствует принципам чистой архитектуры и DDD.

2.1. Интерфейс (Interface)

Поле	Значение
Термин	Интерфейс
Пояснение	Точка входа в компонент. Определяет контракт взаимодействия с внешним миром (пользователем, другим сервисом, инструментом).
Подтипы	`interface:web-ui` — человеко-ориентированный (браузер); `interface:cli` — командная строка; `interface:rest` / `interface:grpc` / `interface:graphql` — программный; `interface:mcp` — агентный протокол.
Правило размещения	UI- и CLI-интерфейсы размещаются в группе `E`. Программные интерфейсы (`rest`, `grpc`) размещаются внутри своего компонента (в `A` или `C`), за исключением шлюза, где они являются внешней точкой входа.
Пример	`E.portal.01 — interface:web-ui`; `A.assets.01 — interface:rest`; `C.did.02 — interface:grpc-9090`.

2.2. Функция (Function)

Поле	Значение
Термин	Функция
Синонимы	Use case, вариант использования, операция
Пояснение	Именованное поведение компонента, реализующее бизнес-правило или техническую операцию. Не является самостоятельным артефактом — существует внутри компонента.
Признаки	Имеет вход и выход; может вызывать другие функции и репозитории; не имеет собственного сетевого адреса.
Пример	`A.assets.02 — function:passport-crud`; `C.vc.03 — function:revoke`; `C.did.04 — function:signed-ops`.

2.3. Сущность (Entity)

Поле	Значение
Термин	Сущность
Синонимы	Доменная сущность, модель, агрегат
Пояснение	Структура данных, обладающая идентичностью и жизненным циклом. Хранит состояние домена и правила его изменения.
Признаки	Имеет идентификатор; может изменяться во времени; участвует в бизнес-правилах.
Пример	`C.docs-chaincode.01 — entity:kcont-2249`; `I.HLF.01 — entity:peer0-gazprom`.

2.4. Репозиторий / Адаптер (Repository / Adapter)

Поле	Значение
Термин	Репозиторий (адаптер)
Синонимы	Adapter, порт, инфраструктурный слой
Пояснение	Компонент, абстрагирующий доступ к внешнему хранилищу или системе (БД, HLF, внешний API). Реализует интерфейс, определённый в домене.
Признаки	Не содержит бизнес-логики; транслирует вызовы домена в операции хранилища; изолирует домен от инфраструктуры.
Пример	`A.documents.02 — function:hlf-client`; `A.storage.02 — function:file-store`; `C.blockchain-hlf` (адаптер с PostgreSQL и NATS).

3. Правила применения

Каждый компонент в реестре CI должен быть отнесён к одному из типов раздела 1.
Каждый дочерний узел компонента в реестре CI должен быть отнесён к одному из типов раздела 2.
Интерфейс не отрывается от компонента-владельца. Программный интерфейс (rest, grpc) находится внутри своего компонента; перенос в группу E допускается только для шлюзов и пользовательских интерфейсов.
Связи между компонентами (маршрутизация, вызовы, зависимости) описываются отдельной таблицей связей, а не через перенос узлов.
Тип компонента фиксируется в ADR при принятии архитектурного решения о его создании или изменении.

4. Журнал изменений

Дата	Перечень изменений	Автор
2026-11-05	Создан онтологический справочник типов компонентов.	А.М.
2026-11-05	Добавлено оглавление терминов со ссылками на разделы.	А.М., Дис
2026-11-06	Оглавление переведено на якоря заголовков; HTML-якоря `<a id>` удалены.	Дис

Реестр компонентов сервиса did-svc (драфт)

261107_agents_x509