architect/standards/6-naming/naming-terminology.md

type: standard
aspect: naming
title: "СТАНДАРТ ТЕРМИНОЛОГИИ ПЛАТФОРМЫ"
version: 1.0.0
date: 2026-02-19
status: active


СТАНДАРТ ТЕРМИНОЛОГИИ ПЛАТФОРМЫ

Версия: 1.0.0
Дата: 2025-12-22
Уровень: L2 (Стандарт)
Статус: CANONICAL


ОБЗОР

Канонические определения всех терминов платформы.

Правило: Все термины имеют ОДНО точное значение. Многозначность ЗАПРЕЩЕНА.


1. ПРОЕКТ (Project)

1.1. Определение

ПРОЕКТ — это временная организационная сущность для создания/изменения чего-либо.

Ключевые характеристики:
- ✅ Временная (имеет начало и конец)
- ✅ Организационная (не физическая сущность)
- ✅ Целевая (создать/изменить что-то конкретное)
- ✅ Управляемая (есть план, ресурсы, метрики)


1.2. Два значения термина "ПРОЕКТ"

Значение 1: Организационная сущность (Process)

Проект как ПРОЦЕСС работы

ПРОЕКТ (процесс) = Временная деятельность по созданию/изменению

Примеры:
✅ Проект интеграции с OZON        (работа клиентская)
✅ Проект внедрения CRM             (внутренняя работа)
✅ Проект запуска нового сайта      (работа)
✅ Проект миграции БД               (работа)

Характеристики:
- Начало: 2025-12-01
- Конец: 2026-03-31
- Команда: 3 человека
- Бюджет: 500 000₽
- Результат: Работающая интеграция

Каноническое место: /L0-ORG/projects/{name}/

Файлы:
- BRIEF.md — Бриф, постановка задачи
- PLAN.md — План работ
- TEAM.md — Команда проекта
- REPORT.md — Отчёт по завершении


Значение 2: Документация (Specification)

Проект как ДОКУМЕНТАЦИЯ для создания

ПРОЕКТ (документация) = Спецификация/чертёж того что создаём

Примеры:
✅ Проект дома (чертежи)
✅ Проект системы (SPECIFICATION.md)
✅ Проект бизнеса (бизнес-план)

НО ЛУЧШЕ НАЗВАТЬ:
✅ Спецификация системы
✅ Описание бизнеса
✅ План здания

Каноническое место: {entity}/SPECIFICATION.md

НЕ "PROJECT.md"! → Используем SPECIFICATION.md


1.3. Правило использования

┌─────────────────────────────────────────────────────────┐
│  Используй "ПРОЕКТ" ТОЛЬКО для:                         │
│                                                         │
│  1. Временной организационной работы                   │
│     ✅ "Проект интеграции с OZON"                       │
│     ✅ "Проект внедрения CRM"                           │
│                                                         │
│  Для документации используй точные термины:            │
│  ✅ Спецификация системы (SPECIFICATION.md)             │
│  ✅ Описание бизнес-единицы (SPECIFICATION.md)          │
│  ✅ План / Чертёж                                       │
└─────────────────────────────────────────────────────────┘

2. ПОСТОЯННЫЕ СУЩНОСТИ

2.1. Бизнес-единица (Business Unit)

Определение: Постоянная организационная единица, ведущая хозяйственную деятельность.

БИЗНЕС-ЕДИНИЦА = Организация, которая работает непрерывно

Примеры:
✅ pirotehnika    (торговля фейерверками)
✅ lideravto      (торговля автозапчастями)
✅ content-factory (SaaS-продукт)

Характеристики:
- ❌ НЕ временная (работает пока существует)
- ✅ Постоянная
- ✅ Имеет выручку, прибыль, команду
- ✅ Может быть продана/закрыта

Каноническое место: /L0-ORG/business-units/{name}/

Файлы:
- SPECIFICATION.md — Описание бизнеса (9 вопросов)
- CLAUDE.md — Контекст для AI
- index.yaml — Метаданные

ЗАПРЕЩЕНО: "Бизнес-проект" ❌


2.2. ИТ-система (System)

Определение: Программное обеспечение, выполняющее определённые функции.

ИТ-СИСТЕМА = Программа/сервис с определённой функцией

Примеры:
✅ PIM       (Product Information Management)
✅ CRM       (Customer Relationship Management)
✅ Analytics (Аналитическая система)

Характеристики:
- ✅ Постоянная (пока используется)
- ✅ Имеет код, данные, API
- ✅ Обслуживает пользователей
- ✅ Эволюционирует (версии)

Каноническое место: /L1-SERVICE/systems/{name}/

Файлы:
- SPECIFICATION.md — Описание системы (7 вопросов)
- ARCHITECTURE.md — Архитектура
- API.md — API документация

ЗАПРЕЩЕНО: "ИТ-проект" ❌


2.3. Набор данных (Dataset)

Определение: Логически связанная коллекция данных.

НАБОР ДАННЫХ = Коллекция данных с определённой структурой

Примеры:
✅ pim_products     (товары)
✅ customers        (клиенты)
✅ orders           (заказы)

Характеристики:
- ✅ Имеет схему (структуру)
- ✅ Имеет владельца
- ✅ Имеет подключение к хранилищу

Каноническое место: /L2-DATA/datasets/{name}/

Файлы:
- SPECIFICATION.md — Описание набора данных (5 вопросов)
- schema.sql — Схема БД

ЗАПРЕЩЕНО: "Проект данных" ❌


2.4. Инфраструктурный ресурс (Infrastructure Resource)

Определение: Физический или виртуальный ресурс инфраструктуры.

РЕСУРС = Физическая или виртуальная сущность инфраструктуры

Примеры:
✅ beget-kondurov   (физический сервер)
✅ postgresql-001   (инстанс СУБД)
✅ hub              (S3 хранилище)

Характеристики:
- ✅ Физически существует
- ✅ Имеет характеристики (CPU, RAM, Storage)
- ✅ Может быть общим или выделенным

Каноническое место: /L3-INFRA/{type}/{name}/

Файлы:
- SPECIFICATION.md — Описание ресурса
- config.yaml — Конфигурация

ЗАПРЕЩЕНО: "Проект инфраструктуры" ❌


3. СТРУКТУРНЫЕ ЭЛЕМЕНТЫ

3.1. Канал продаж (Sales Channel)

Определение: Способ взаимодействия бизнеса с клиентами.

КАНАЛ = Путь продажи товаров/услуг клиентам

Примеры:
✅ retail       (розничная торговля через сайт)
✅ ozon         (маркетплейс OZON)
✅ wholesale    (оптовые продажи)

Характеристики:
- ✅ Принадлежит бизнес-единице
- ✅ Имеет свою специфику
- ✅ Генерирует выручку

Каноническое место: /L0-ORG/business-units/{unit}/channels/{name}/


3.2. Операция (Operation)

Определение: Постоянная функция/процесс в бизнес-единице.

ОПЕРАЦИЯ = Постоянная функция бизнеса

Примеры:
✅ logistics    (логистика)
✅ warehouse    (склад)
✅ procurement  (закупки)
✅ pim          (управление товарами)

Характеристики:
- ✅ Постоянная функция
- ✅ Обслуживает бизнес
- ✅ Имеет процессы и ресурсы

Каноническое место: /L0-ORG/business-units/{unit}/operations/{name}/


3.3. Направление (Direction)

Определение: Стратегическое направление развития (используется редко).

НАПРАВЛЕНИЕ = Стратегический вектор развития

РЕКОМЕНДАЦИЯ: Не использовать, заменить на:
- Канал продаж (для продаж)
- Операция (для функций)

Статус: DEPRECATED, использовать Channel или Operation


4. ТИПЫ СИСТЕМ (по роли)

4.1. Целевая система (Target System)

Определение: Система, создающая ценность для конечного клиента.

ЦЕЛЕВАЯ = Продаём клиентам, решаем их проблему

Примеры:
✅ Сайт pirotehnika.spb.ru   (клиенты покупают товары)
✅ SaaS платформа            (клиенты используют)
✅ Мобильное приложение       (клиенты используют)

Вопросов: 9 (ПОЧЕМУ, ЗАЧЕМ, ЧТО, КТО, КАК, ЧЕМ, ГДЕ, КОГДА, СКОЛЬКО)

4.2. Обеспечивающая система (Supporting System)

Определение: Система, обслуживающая другие системы.

ОБЕСПЕЧИВАЮЩАЯ = Поддерживает другие системы

Примеры:
✅ PIM          (данные для сайта и маркетплейсов)
✅ 1C           (учёт для всех бизнесов)
✅ Логистика    (доставка для торговли)

Вопросов: 7 (нет ПОЧЕМУ и ЗАЧЕМ, есть ПРИНЦИПЫ и МИССИЯ)

4.3. Информационная система (Information System)

Определение: Система для хранения и передачи знаний.

ИНФОРМАЦИОННАЯ = Хранит и передаёт информацию

Примеры:
✅ Architect       (методология)
✅ База знаний     (документация)
✅ Wiki            (знания компании)

Вопросов: 5 (ЧТО, ЧЕМ, КАК, ГДЕ, СКОЛЬКО)

4.4. Процесс (Process)

Определение: Последовательность действий для достижения результата.

ПРОЦЕСС = Workflow, преобразование входа в выход

Примеры:
✅ Логистика           (заказ → доставленный товар)
✅ Производство        (сырьё → продукт)
✅ Обработка заказа    (новый заказ → выполненный)

Вопросов: 8 (ПОЧЕМУ, ЗАЧЕМ, ВХОД, ВЫХОД, КТО, КАК, ЧЕМ, ГДЕ)

4.5. Агент (Agent)

Определение: Автономная система, действующая самостоятельно.

АГЕНТ = Автономная система с собственным поведением

Примеры:
✅ Telegram бот        (общается с пользователями)
✅ Worker синхронизации (автоматически синхронизирует данные)
✅ Мониторинг          (отслеживает и реагирует)

Вопросов: 6 (ЗАЧЕМ, ЧТО, КТО, КАК, ЧЕМ, ГДЕ)

5. УРОВНИ ИЕРАРХИИ

5.1. L0: ORG (Организация)

Определение: Организационная структура (бизнесы, проекты).

L0:ORG = Как мы организованы

Содержит:
- business-units/      (постоянные бизнесы)
- projects/            (временные работы)
- methodology/         (методология)

5.2. L1: SERVICE (Сервисы)

Определение: Бизнес-логика и интерфейсы.

L1:SERVICE = Что делают системы

Содержит:
- systems/             (ИТ-системы)
  - api/               (REST/GraphQL)
  - ui/                (Web/Mobile)
  - cli/               (Командная строка)
  - processors/        (ETL обработки)

5.3. L2: DATA (Данные)

Определение: Структуры данных и подключения.

L2:DATA = Как работать с данными

Содержит:
- connections/         (подключения к ресурсам)
- datasets/            (наборы данных)
- schemas/             (схемы структур)

5.4. L3: INFRA (Инфраструктура)

Определение: Физические и виртуальные ресурсы.

L3:INFRA = Физическая база

Содержит:
- compute/             (серверы, VM, контейнеры)
- storage/             (хранилища)
- network/             (сеть, домены)
- database-engines/    (СУБД инстансы)

6. ТИПЫ СВЯЗЕЙ

6.1. Вертикальные связи

Связь Направление Значение Пример
extends Вниз (L0→L3) Наследование/специализация L1 extends L2
uses Вниз Использование ресурса L0 uses L1
mount Вниз Монтирование service → dataset

6.2. Горизонтальные связи

Связь Направление Значение Пример
calls Любое Вызов API pim → analytics
depends_on Любое Зависимость site → pim
provides_to Любое Предоставление сервиса pim ⇒ site

7. ТИПЫ РЕСУРСОВ

7.1. База данных

Термин Значение Уровень изоляции Пример
Server Физический сервер СУБД Максимальная db-server-01
Instance Инстанс СУБД (процесс) Высокая postgresql-001
Database База данных (catalog) Средняя nocodb
Schema Схема (namespace) Низкая bu_piro
Table Prefix Префикс таблиц Минимальная piro_

7.2. Хранилище

Термин Значение Пример
Server Физический сервер хранилища NAS, SAN
Bucket S3 bucket hub
Path Путь внутри bucket /business-units/pirotehnika/
Volume Блочное хранилище Docker volume

7.3. Вычисления

Термин Значение Пример
Physical Server Физический сервер beget-kondurov
VM Виртуальная машина dev-vm-01
Container Docker контейнер sys-pim-prod
Process Процесс в ОС pid 1234

8. ФАЙЛЫ ДОКУМЕНТАЦИИ

8.1. Стандартные файлы

Файл Назначение Используется для
SPECIFICATION.md Спецификация сущности ВСЕ сущности (9/7/5 вопросов)
ARCHITECTURE.md Архитектура ИТ-системы
API.md API документация Сервисы с API
README.md Краткое введение ВСЕ сущности
CLAUDE.md Контекст для AI Проекты, системы, бизнесы
index.yaml Метаданные ВСЕ сущности
BRIEF.md Бриф от клиента Клиентские проекты
PLAN.md План работ Проекты
REPORT.md Отчёт Проекты (по завершении)

8.2. ЗАПРЕЩЁННЫЕ названия

❌ PROJECT.md              → Используй SPECIFICATION.md
❌ DESCRIPTION.md          → Используй SPECIFICATION.md
❌ INFO.md                 → Используй README.md
❌ DOCS.md                 → Используй README.md или API.md

9. ПРАВИЛА ИМЕНОВАНИЯ

9.1. Директории

Формат: lowercase-with-dashes

Примеры:
 business-units
 client-projects
 database-engines
 sales-channels

 BusinessUnits
 client_projects
 Database-Engines

9.2. Коды сущностей

Формат: 4-6 букв, lowercase

Примеры:
 piro         (pirotehnika)
 lider        (lideravto)
 sys          (system)
 bu           (business unit)

Использование:
- Префиксы в БД: bu_piro, sys_pim
- Коды ресурсов: piro-db, lider-s3

10. ГЛОССАРИЙ (алфавитный порядок)

Термин (рус) Термин (eng) Определение Пример
Агент Agent Автономная система Telegram бот
Бизнес-единица Business Unit Постоянная орг. единица pirotehnika
Данные Data Информация в структурированном виде pim_products
Инфраструктура Infrastructure Физические ресурсы Сервер, БД
ИТ-система System Программное обеспечение PIM, CRM
Канал продаж Sales Channel Путь к клиенту retail, ozon
Набор данных Dataset Коллекция данных customers
Операция Operation Постоянная функция logistics
Проект Project Временная работа Проект интеграции
Ресурс Resource Инфра-сущность Сервер, БД инстанс
Сервис Service Логика + интерфейс API, UI
Спецификация Specification Описание сущности SPECIFICATION.md

ПРИЛОЖЕНИЕ A: Запрещённые термины

❌ "Проект" без уточнения (используй точные термины)
❌ "Направление" (используй Channel или Operation)
❌ "PROJECT.md" (используй SPECIFICATION.md)
❌ "Данные" в значении "код работы с данными" (используй Connection, Schema)

ПРИЛОЖЕНИЕ B: Связь с PROJECTOR

PROJECTOR должен оперировать этими терминами:

projector:
  entity_types:
    - business-unit
    - system
    - dataset
    - project           # Только для временных работ!

  forbidden_terms:
    - "бизнес-проект"
    - "ИТ-проект"
    - "проект данных"
    - "направление" (вместо channel)

  standard_files:
    - SPECIFICATION.md  # НЕ PROJECT.md!
    - ARCHITECTURE.md
    - README.md
    - CLAUDE.md
    - index.yaml

Статус: CANONICAL — обязательно к применению
Дата утверждения: 2025-12-22