architect/standards/4-policy/policy-resource-allocation.md

type: standard
aspect: policy
title: "СТАНДАРТЫ ВЫДЕЛЕНИЯ РЕСУРСОВ"
version: 1.0.0
date: 2026-02-19
status: active


СТАНДАРТЫ ВЫДЕЛЕНИЯ РЕСУРСОВ

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


ОБЗОР

Определяет стандарты выделения и изоляции ресурсов при создании новых сущностей:
- Какие ресурсы выделяются по умолчанию
- Уровни изоляции
- Правила именования
- Политики шаринга


1. ТЕРМИНОЛОГИЯ

1.1. Единицы изоляции в БД

Термин Что это Уровень изоляции Пример
Server Физический/виртуальный сервер СУБД Максимальная postgresql-001
Instance Инстанс СУБД (процесс) Высокая postgres:5432, mysql:3306
Database База данных (catalog) Средняя nocodb, pirotehnika_db
Schema Схема (namespace) Низкая pt7k98pv0fwi1el, public
Table Prefix Префикс таблиц Минимальная piro_, lider_

PostgreSQL терминология:

Server (физический сервер)
└── Instance (процесс postgres)
    └── Database (catalog)
        └── Schema (namespace)
            └── Tables (таблицы)

MySQL терминология:

Server
└── Instance (mysqld)
    └── Database (= Schema в MySQL)
        └── Tables

1.2. Уровни изоляции

Уровень Название Описание Когда использовать
L0: Shared Общий ресурс Префикс в общей БД Dev окружение, мелкие проекты
L1: Isolated Изолированный Отдельная схема/БД Production, средние проекты
L2: Dedicated Выделенный Отдельный инстанс Критичные системы
L3: Standalone Автономный Отдельный сервер Высоконагруженные, критичные

1.3. Типы ресурсов

Ресурс Что выделяется Пример
Compute CPU, RAM, процессы Container, VM, Server
Storage Диск, объектное хранилище Volume, Bucket, Directory
Database База данных, схема PostgreSQL schema, MySQL database
Network Домен, порты, IP pirotehnika.spb.ru, port 8080
Credentials Логины, ключи, токены DB user, API key, S3 credentials

2. СТАНДАРТЫ ПО ТИПАМ СУЩНОСТЕЙ

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

Уровень: L0-ORG/business-units/{name}/

Стандартные ресурсы:

business-unit:
  name: pirotehnika

  resources:
    database:
      isolation: isolated          # Отдельная схема
      instance: shared-postgresql  # Общий инстанс
      schema: piro_*               # Схема с префиксом
      naming: "{unit_code}_*"      # piro_products, piro_orders

    storage:
      isolation: isolated          # Отдельный bucket/path
      type: s3
      bucket: hub
      path: "/business-units/pirotehnika/"

    network:
      domains:
        - pirotehnika.spb.ru
        - www.pirotehnika.spb.ru

    credentials:
      isolation: dedicated         # Свои credentials
      storage: vault
      path: "/business-units/pirotehnika/"

Политика по умолчанию:
- ✅ Отдельная схема в общей БД
- ✅ Отдельный path в общем S3
- ✅ Собственные credentials
- ❌ НЕ отдельный инстанс (если не требуется)


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

Уровень: L0-ORG/business-units/{unit}/channels/{name}/

Стандартные ресурсы:

channel:
  name: retail
  business_unit: pirotehnika

  resources:
    database:
      isolation: shared            # Префикс внутри схемы бизнеса
      schema: piro_retail          # Схема канала
      naming: "retail_*"           # retail_orders, retail_customers

    storage:
      path: "/business-units/pirotehnika/channels/retail/"

    network:
      domains:
        - pirotehnika.spb.ru       # Основной домен бизнеса

Политика по умолчанию:
- ✅ Наследует ресурсы бизнес-единицы
- ✅ Префикс таблиц для разделения
- ❌ НЕ отдельная схема (если не требуется)


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

Уровень: L1-SERVICE/systems/{name}/

Стандартные ресурсы:

system:
  name: pim
  type: service

  resources:
    database:
      isolation: isolated          # Отдельная схема
      instance: shared-postgresql
      schema: pim_*
      naming: "pim_*"              # pim_products, pim_brands

    storage:
      isolation: isolated
      path: "/systems/pim/"

    compute:
      isolation: shared            # Общий Docker/K8s
      type: container
      limits:
        cpu: "1"
        memory: "2Gi"

    network:
      ports:
        - 8080                     # API port
      internal_domain: pim.internal

    credentials:
      isolation: dedicated
      path: "/systems/pim/"

Политика по умолчанию:
- ✅ Отдельная схема в общей БД
- ✅ Отдельный path в S3
- ✅ Container в общем кластере
- ✅ Собственные credentials
- ❌ НЕ отдельный инстанс БД


2.4. Клиентский проект (Client Project)

Уровень: L0-ORG/client-projects/{name}/

Стандартные ресурсы:

client-project:
  name: ozon-integration

  resources:
    database:
      isolation: shared            # Обычно использует существующие
      # ИЛИ временная БД для разработки:
      schema: temp_ozon_integration
      lifetime: 3_months           # Временная

    storage:
      path: "/client-projects/ozon-integration/"
      lifetime: 6_months           # Архивируется после завершения

    compute:
      isolation: shared            # Dev окружение

Политика по умолчанию:
- ✅ Использует ресурсы существующих систем
- ✅ Временные ресурсы (удаляются после завершения)
- ❌ НЕ создаёт постоянные ресурсы


3. МАТРИЦА ВЫДЕЛЕНИЯ РЕСУРСОВ

3.1. По типу сущности

Сущность Database Storage Compute Network Credentials
Business Unit Schema Path Inherited Domain Dedicated
Channel Prefix Sub-path Inherited Sub-domain Inherited
System Schema Path Container Port Dedicated
Client Project Temp/Shared Temp path Shared - Shared
Dataset Tables Files - - Inherited

3.2. По уровню изоляции

Изоляция Database Storage Compute Примеры
Shared Table prefix Shared path Shared host Dev, Testing
Isolated Schema/DB Bucket path Container Production (обычно)
Dedicated Instance Dedicated bucket VM Критичные системы
Standalone Server Dedicated storage Physical server Высоконагруженные

4. ПРАВИЛА ИМЕНОВАНИЯ РЕСУРСОВ

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

Формат: {entity_type}_{entity_name}_{resource_type}

Примеры:
├── bu_pirotehnika                Business Unit schema
├── bu_lideravto
├── sys_pim                       System schema
├── sys_crm
├── chan_retail                   Channel schema
└── temp_project_ozon             Temporary (client project)

Правила:
- bu_ — Business Unit
- sys_ — System
- chan_ — Channel
- temp_ — Temporary resource
- Lowercase, underscore separator
- Максимум 63 символа (PostgreSQL limit)


4.2. Таблицы

Формат: {prefix}_{table_name}

Примеры:
Business Unit (pirotehnika):
├── piro_products
├── piro_orders
├── piro_customers
└── piro_analytics

System (PIM):
├── pim_products
├── pim_brands
└── pim_categories

Channel (retail):
├── retail_cart
├── retail_wishlist
└── retail_reviews

4.3. Storage paths

Формат: /{level}/{type}/{name}/

Примеры:
/business-units/pirotehnika/
/business-units/pirotehnika/channels/retail/
/systems/pim/
/systems/crm/
/client-projects/ozon-integration/
/temp/2025-12-22-experiment/

4.4. Containers/Services

Формат: {type}-{name}-{env}

Примеры:
sys-pim-prod                      System в production
sys-pim-dev                       System в dev
bu-pirotehnika-site-prod          Business Unit site
temp-ozon-integration-dev         Temporary project

5. ШАБЛОНЫ ВЫДЕЛЕНИЯ РЕСУРСОВ

5.1. Шаблон для новой бизнес-единицы

# Template: business-unit-resources.yaml
business_unit:
  code: "{unit_code}"              # 4-6 букв, например: piro, lider
  name: "{full_name}"

  allocate:
    database:
      instance: /L3-INFRA/database-engines/postgresql-001
      action: create_schema
      schema: "bu_{unit_code}"
      owner: "bu_{unit_code}_owner"
      credentials:
        user: "bu_{unit_code}_rw"
        password: generate_random
        vault_path: "/business-units/{unit_code}/db"

    storage:
      provider: /L3-INFRA/storage/object/s3/hub
      action: create_path
      path: "/business-units/{unit_code}/"
      credentials:
        access_key: generate_random
        secret_key: generate_random
        vault_path: "/business-units/{unit_code}/s3"

    network:
      action: register_domain
      primary_domain: "{unit_code}.example.com"

  inherit_from:
    - /GROUP/shared/connectors/postgresql
    - /GROUP/shared/templates/business-unit

Применение:

# Создать ресурсы для новой бизнес-единицы
architect create business-unit --code piro --name "Pirotehnika"

# Создаст:
# - Schema: bu_piro
# - DB User: bu_piro_rw
# - S3 Path: /business-units/piro/
# - Credentials в vault

5.2. Шаблон для новой системы

# Template: system-resources.yaml
system:
  name: "{system_name}"
  type: "{service|data|integration}"

  allocate:
    database:
      instance: /L3-INFRA/database-engines/postgresql-001
      action: create_schema
      schema: "sys_{system_name}"
      owner: "sys_{system_name}_owner"

    storage:
      provider: /L3-INFRA/storage/object/s3/hub
      path: "/systems/{system_name}/"

    compute:
      provider: /L3-INFRA/compute/containers/docker
      action: create_container
      image: "{system_name}:latest"
      resources:
        cpu: "1"
        memory: "2Gi"
      ports:
        - 8080

  inherit_from:
    - /GROUP/shared/connectors/postgresql
    - /GROUP/shared/templates/system

5.3. Шаблон для канала продаж

# Template: channel-resources.yaml
channel:
  name: "{channel_name}"
  business_unit: "{parent_unit_code}"

  allocate:
    database:
      # Наследует схему от бизнес-единицы
      schema: "bu_{parent_unit_code}"
      # Создаёт таблицы с префиксом
      table_prefix: "{channel_name}_"

    storage:
      # Наследует path от бизнес-единицы
      path: "/business-units/{parent_unit_code}/channels/{channel_name}/"

  inherit_from:
    - /L0-ORG/business-units/{parent_unit_code}
    - /GROUP/shared/templates/channel

6. ПОЛИТИКИ НАСЛЕДОВАНИЯ

6.1. Принцип наследования ресурсов

Parent → Child наследует по умолчанию

Business Unit (pirotehnika)
├── database: bu_piro
├── storage: /business-units/pirotehnika/
├── credentials: vault:/business-units/pirotehnika/
    ↓ inherits

Channel (retail)
├── database: bu_piro                              ← Наследовано
├── table_prefix: retail_                          ← Добавлено
├── storage: /business-units/pirotehnika/channels/retail/  ← Специализировано
└── credentials: vault:/business-units/pirotehnika/        ← Наследовано

Правила наследования:
1. По умолчанию: Наследуем всё от родителя
2. Специализация: Можем добавить свои ресурсы
3. Переопределение: Можем переопределить (требует обоснования)
4. Изоляция: Можем повысить уровень изоляции (но не понизить)


6.2. Переопределение ресурсов

# Пример: Channel требует отдельную схему (переопределение)
channel:
  name: ozon
  business_unit: pirotehnika

  override:
    database:
      reason: "High load, needs isolation"
      schema: "bu_piro_ozon"           ← Отдельная схема
      isolation: isolated               ← Повышена изоляция

  allocate:
    compute:
      reason: "Critical integration"
      type: dedicated                   ← Выделенный контейнер
      resources:
        cpu: "2"
        memory: "4Gi"

Требования для переопределения:
- ✅ Указать причину (reason)
- ✅ Можно повышать уровень изоляции
- ❌ Нельзя понижать уровень изоляции
- ⚠️ Требуется review/approval


7. МАТРИЦА ИЗОЛЯЦИИ ПО ОКРУЖЕНИЯМ

7.1. По окружениям

Окружение Database Storage Compute Credentials
Development Shared (prefix) Shared path Shared host Shared
Staging Isolated (schema) Isolated path Container Dedicated
Production Isolated (schema) Isolated path Container/VM Dedicated
Critical Prod Dedicated (instance) Dedicated bucket VM/Server Dedicated

7.2. Пример: PIM в разных окружениях

# Development
pim-dev:
  database:
    schema: dev_common
    prefix: pim_
  storage:
    path: /dev/pim/
  compute:
    host: dev-shared

# Staging
pim-staging:
  database:
    schema: staging_pim
  storage:
    path: /staging/pim/
  compute:
    container: pim-staging

# Production
pim-prod:
  database:
    schema: pim_prod
  storage:
    path: /production/pim/
  compute:
    container: pim-prod
    resources:
      cpu: "2"
      memory: "4Gi"

8. ПРОЦЕДУРЫ ВЫДЕЛЕНИЯ РЕСУРСОВ

8.1. Lifecycle ресурсов

1. REQUEST      Запрос на ресурсы (template + params)
2. REVIEW       Проверка необходимости
3. APPROVE      Утверждение (для dedicated+)
4. ALLOCATE     Выделение ресурсов
5. CONFIGURE    Настройка и подключение
6. DOCUMENT     Документирование в index.yaml
7. MONITOR      Мониторинг использования
8. CLEANUP      Удаление при необходимости

8.2. Команды выделения

# Создать бизнес-единицу
architect resource allocate business-unit \
  --code piro \
  --name "Pirotehnika" \
  --template business-unit-resources.yaml

# Создать систему
architect resource allocate system \
  --name pim \
  --type service \
  --isolation isolated \
  --template system-resources.yaml

# Создать канал
architect resource allocate channel \
  --name retail \
  --parent pirotehnika \
  --template channel-resources.yaml

# Создать временные ресурсы для проекта
architect resource allocate temp \
  --name ozon-integration \
  --lifetime 3months \
  --template temp-project-resources.yaml

8.3. Документирование в index.yaml

# L0-ORG/business-units/pirotehnika/index.yaml
name: "Pirotehnika"
type: business-unit
code: piro

resources:
  allocated:
    database:
      instance: /L3-INFRA/database-engines/postgresql-001
      schema: bu_piro
      user: bu_piro_rw
      connection: /L2-DATA/connections/bu-piro-db

    storage:
      provider: /L3-INFRA/storage/object/s3/hub
      path: /business-units/pirotehnika/
      connection: /L2-DATA/connections/bu-piro-s3

    credentials:
      vault_path: /business-units/pirotehnika/

  inherited_by:
    - /L0-ORG/business-units/pirotehnika/channels/retail
    - /L0-ORG/business-units/pirotehnika/channels/ozon

9. ПРАВИЛА ОЧИСТКИ РЕСУРСОВ

9.1. Временные ресурсы

temp_resources:
  retention:
    client_projects:
      active: keep
      completed: 6_months      # Архивировать через 6 месяцев
      archived: 2_years        # Удалить через 2 года

    dev_experiments:
      active: keep
      inactive_30d: archive    # Архивировать если не используется 30 дней
      archived: 3_months       # Удалить через 3 месяца

9.2. Неиспользуемые ресурсы

cleanup_policy:
  database:
    empty_schemas:
      check: monthly
      action: notify_owner

    unused_30d:
      check: monthly
      action: archive_candidate

  storage:
    empty_paths:
      check: weekly
      action: delete_after_30d

  compute:
    stopped_containers:
      check: daily
      action: delete_after_7d

10. БЕЗОПАСНОСТЬ И ДОСТУП

10.1. Принцип наименьших привилегий

access_policy:
  business_unit:
    owner: full_access
    members: read_write
    guests: read_only

  system:
    service_account: read_write
    developers: read_only_prod, read_write_dev
    ops: full_access

  temporary_project:
    project_team: full_access
    expires_with_project: true

10.2. Изоляция credentials

Правило: Каждая сущность имеет собственные credentials

Business Unit: bu_piro_rw / bu_piro_ro
System: sys_pim_rw / sys_pim_ro
Channel: наследует от Business Unit ИЛИ собственные

Хранение: HashiCorp Vault
Path: /{level}/{type}/{name}/credentials

11. ГРАНИЦЫ ИЗОЛЯЦИИ ПО УРОВНЯМ

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

Минимальная изоляция: Shared
- Database: Table prefix в общей схеме
- Storage: Sub-path в общем bucket
- Compute: Shared host/container
- Credentials: Shared (не рекомендуется для production)

Максимальная изоляция: Standalone
- Database: Отдельный сервер БД
- Storage: Отдельное хранилище
- Compute: Отдельный физический/виртуальный сервер
- Credentials: Dedicated vault instance

По умолчанию: Isolated
- Database: Отдельная схема (schema)
- Storage: Изолированный path
- Credentials: Dedicated

Правило повышения:
- Business Unit может повысить до Dedicated/Standalone при обосновании
- Понижение изоляции ЗАПРЕЩЕНО после production deployment


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

Минимальная изоляция: Shared
- Database: Table prefix внутри схемы parent
- Compute: Shared container/process
- Storage: Sub-path

Максимальная изоляция: Dedicated
- Database: Отдельный instance (НЕ server)
- Compute: Dedicated VM/container
- Storage: Dedicated bucket

По умолчанию: Isolated
- Database: Отдельная схема
- Compute: Container с resource limits
- Storage: Isolated path

Особенности:
- Сервис БЕЗ state: может работать на Shared compute
- Сервис С state: минимум Isolated database
- Критичный сервис: минимум Isolated, рекомендуется Dedicated

Правило:
- L1-SERVICE не может иметь Standalone (отдельный server)
- Максимум: Dedicated instance/VM
- Если нужен Standalone → это L3-INFRA


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

Минимальная изоляция: Shared
- Database: Таблицы в общей схеме с префиксом
- Storage: Shared path с sub-directories

Максимальная изоляция: Isolated
- Database: Отдельная схема
- Storage: Isolated path/bucket

По умолчанию: Isolated
- Database: Отдельная схема для connections/schemas
- Storage: Isolated path

Особенности:
- L2-DATA НЕ владеет физическими ресурсами
- L2-DATA описывает подключения к L3-INFRA
- Изоляция определяется целевым ресурсом

Правило:
- L2-DATA НИКОГДА не имеет Dedicated/Standalone
- Максимум: Isolated (отдельная схема для метаданных)
- Фактические данные живут в L3-INFRA


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

Минимальная изоляция: Shared
- Shared process (например: shared PostgreSQL instance)
- Shared storage pool
- Shared network

Максимальная изоляция: Standalone
- Отдельный физический сервер
- Отдельная сеть
- Отдельный datacenter (extreme cases)

По умолчанию: Dedicated
- Dedicated instance (процесс)
- Dedicated volume/bucket
- Dedicated network segment

Особенности:
- L3-INFRA управляет ФИЗИЧЕСКИМИ ресурсами
- Может предоставлять разные уровни изоляции для upper levels
- Пример: PostgreSQL instance (L3) → предоставляет schemas (L2/L1/L0)

Правило:
- Production infrastructure: минимум Dedicated
- Development infrastructure: может быть Shared
- Critical infrastructure: Standalone


11.5. Матрица границ изоляции

Уровень Минимум По умолчанию Максимум Примечание
L0: ORG Shared (prefix) Isolated (schema) Standalone (server) Может повышать до Standalone
L1: SERVICE Shared (prefix) Isolated (schema) Dedicated (instance) НЕ может Standalone
L2: DATA Shared (prefix) Isolated (schema) Isolated (schema) НЕ владеет ресурсами
L3: INFRA Shared (process) Dedicated (instance) Standalone (server) Владеет физикой

11.6. Правила изменения изоляции

Повышение изоляции:

Shared → Isolated → Dedicated → Standalone
  ✅       ✅          ✅           ✅

Понижение изоляции:

Standalone → Dedicated → Isolated → Shared
   ❌           ❌          ❌         ❌

Временное повышение:

# Можно временно повысить для нагрузочных тестов
load_test:
  duration: 7_days
  isolation: dedicated
  rollback_to: isolated

12. ПЛАТФОРМЕННЫЕ ПРИЛОЖЕНИЯ

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

ПЛАТФОРМЕННОЕ ПРИЛОЖЕНИЕ — переиспользуемый сервис, который может использоваться любыми проектами/бизнес-единицами.

Примеры:
- NocoDB (low-code database)
- n8n (workflow automation)
- Metabase (analytics)
- MinIO (object storage)


12.2. Размещение

/PLATFORM/
├── applications/          ← ЗДЕСЬ
│   ├── nocodb/
│   ├── n8n/
│   ├── metabase/
│   └── minio/
│
└── infrastructure/        ← Базовая инфраструктура
    ├── postgresql/
    ├── redis/
    └── nginx/

12.3. Стандартные ресурсы

platform_application:
  name: nocodb
  type: platform_app
  scope: shared              # Доступно всем

  resources:
    database:
      isolation: isolated    # Своя схема
      instance: /L3-INFRA/database-engines/postgresql-001
      schema: platform_nocodb

    storage:
      isolation: isolated
      path: /platform/applications/nocodb/

    compute:
      isolation: dedicated   # Свой контейнер
      container: platform-nocodb-prod
      resources:
        cpu: "2"
        memory: "4Gi"

    network:
      domain: nocodb.platform.internal
      ports:
        - 8080

  used_by:
    - /L0-ORG/business-units/pirotehnika/services/pim
    - /L0-ORG/business-units/lideravto/services/crm

  usage_tracking:
    enabled: true
    metrics:
      - api_calls
      - storage_used
      - active_users

Политика по умолчанию:
- ✅ Isolated database schema
- ✅ Dedicated compute (свой контейнер)
- ✅ Shared credentials (multi-tenant)
- ✅ Usage tracking


12.4. Использование платформенных приложений

# L0-ORG/business-units/pirotehnika/services/pim/index.yaml
service:
  name: pim
  business_unit: pirotehnika
  type: business_unit_service

  resources:
    database:
      # Наследует от бизнес-единицы
      schema: bu_piro
      prefix: pim_

    uses_platform_apps:
      - name: nocodb
        app: /PLATFORM/applications/nocodb
        workspace: piro-pim
        credentials:
          vault_path: /business-units/pirotehnika/services/pim/nocodb

    uses_infra:
      - /L3-INFRA/database-engines/postgresql-001

12.5. Отличие: Платформенное приложение vs Инфраструктура

Характеристика Platform Application Infrastructure
Примеры NocoDB, n8n, Metabase PostgreSQL, Redis, Nginx
Интерфейс UI/API для end-users API для систем
Multi-tenancy Да (workspaces) Нет (изоляция на уровне схем)
Переиспользование Один инстанс для всех Может быть dedicated
Конфигурация Per workspace Per instance

12.6. Шаблон для нового платформенного приложения

# Template: platform-app-resources.yaml
platform_application:
  name: "{app_name}"
  version: "{version}"

  allocate:
    database:
      instance: /L3-INFRA/database-engines/postgresql-001
      action: create_schema
      schema: "platform_{app_name}"

    storage:
      provider: /L3-INFRA/storage/object/s3/hub
      path: "/platform/applications/{app_name}/"

    compute:
      provider: /L3-INFRA/compute/containers/docker
      action: create_container
      image: "{app_name}:{version}"
      resources:
        cpu: "2"
        memory: "4Gi"
      ports:
        - 8080

    network:
      domain: "{app_name}.platform.internal"

  multi_tenancy:
    enabled: true
    isolation_level: workspace

  inherit_from:
    - /PLATFORM/templates/platform-app

13. СЕРВИСЫ БИЗНЕС-ЕДИНИЦЫ

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

СЕРВИС БИЗНЕС-ЕДИНИЦЫ — сервис, который принадлежит конкретной бизнес-единице и работает только для неё.

Примеры:
- PIM для pirotehnika
- Loyalty program для lideravto


13.2. Размещение

/L0-ORG/business-units/pirotehnika/
├── index.yaml
├── SPECIFICATION.md
├── services/              ← ЗДЕСЬ
│   ├── pim/
│   ├── analytics/
│   └── integration-hub/
└── channels/
    └── retail/

13.3. Стандартные ресурсы

business_unit_service:
  business_unit: pirotehnika
  name: pim
  type: service

  resources:
    database:
      # Наследует от бизнес-единицы
      schema: bu_piro
      prefix: pim_                    # Префикс таблиц
      tables:
        - pim_products
        - pim_brands
        - pim_categories

    storage:
      # Специализирует путь
      path: /business-units/pirotehnika/services/pim/

    compute:
      isolation: shared               # В контексте бизнес-единицы
      # ИЛИ использует платформенное приложение:
      uses_app: /PLATFORM/applications/nocodb

  uses_platform_apps:
    - nocodb                          # Использует NocoDB

  credentials:
    # Наследует от бизнес-единицы
    vault_path: /business-units/pirotehnika/services/pim/

Политика по умолчанию:
- ✅ Наследует database schema от business unit
- ✅ Префикс таблиц для разделения
- ✅ Может использовать платформенные приложения
- ✅ Свой sub-path в storage
- ❌ НЕ отдельная схема (если не обосновано)


13.4. Матрица: Приложение vs Сервис бизнеса

Характеристика Platform Application Business Unit Service
Владелец Платформа Бизнес-единица
Scope Все проекты Один проект
Database Своя схема Префикс в схеме бизнеса
Переиспользование Многократное Нет
Изоляция Isolated/Dedicated Shared/Isolated
Примеры NocoDB, n8n PIM для pirotehnika

14. ПРИМЕРЫ

14.1. Создание новой бизнес-единицы "LiderAvto"

business_unit:
  code: lider
  name: "LiderAvto"

resources_allocated:
  database:
    instance: /L3-INFRA/database-engines/postgresql-001
    schema: bu_lider
    tables: []
    user: bu_lider_rw

  storage:
    path: /business-units/lideravto/
    size_limit: 100GB

  network:
    domain: lideravto.ru

  credentials:
    vault_path: /business-units/lideravto/

connections_created:
  - /L2-DATA/connections/bu-lider-db
  - /L2-DATA/connections/bu-lider-s3

14.2. Создание платформенного приложения "NocoDB"

platform_application:
  name: nocodb
  version: "0.200.0"

resources_allocated:
  database:
    instance: /L3-INFRA/database-engines/postgresql-001
    schema: platform_nocodb

  storage:
    path: /platform/applications/nocodb/

  compute:
    container: platform-nocodb-prod
    image: nocodb/nocodb:0.200.0
    resources:
      cpu: "2"
      memory: "4Gi"
    ports:
      - 8080

  network:
    domain: nocodb.platform.internal

used_by:
  - /L0-ORG/business-units/pirotehnika/services/pim
  - /L0-ORG/business-units/lideravto/services/crm

connections_created:
  - /L2-DATA/connections/platform-nocodb-db

14.3. Создание сервиса бизнес-единицы "PIM для Pirotehnika"

business_unit_service:
  business_unit: pirotehnika
  name: pim
  type: service

resources_allocated:
  database:
    # Наследует схему от бизнес-единицы
    instance: /L3-INFRA/database-engines/postgresql-001
    schema: bu_piro             # Схема бизнеса
    prefix: pim_                # Префикс для таблиц
    tables:
      - pim_products
      - pim_brands
      - pim_categories
      - pim_attributes

  storage:
    # Специализирует путь
    path: /business-units/pirotehnika/services/pim/

  uses_platform_apps:
    - name: nocodb
      app: /PLATFORM/applications/nocodb
      workspace: piro-pim
      credentials:
        vault_path: /business-units/pirotehnika/services/pim/nocodb

inherited_from:
  - /L0-ORG/business-units/pirotehnika

connections_created:
  - /L2-DATA/connections/bu-piro-pim-nocodb

15. ОПРЕДЕЛЕНИЕ vs ИСПОЛЬЗОВАНИЕ СЕРВИСА

15.1. Два уровня абстракции

ОПРЕДЕЛЕНИЕ (класс, спецификация):
- Что делает сервис
- Какие компоненты имеет (таблицы, API, UI)
- Какие функции предоставляет
- Независимо от конкретного использования

ИСПОЛЬЗОВАНИЕ (инстанс, подключение):
- Где развернут сервис
- Как к нему подключиться
- Кто может использовать
- Конкретная конфигурация


15.2. Пример: PIM

Определение сервиса PIM

# /PLATFORM/applications/pim/SPECIFICATION.md
type: platform_application
name: pim
description: "Product Information Management"

components:
  database:
    tables:
      - name: pim_products
        fields:
          - id: bigint
          - name: varchar
          - sku: varchar
          - brand_id: bigint

      - name: pim_brands
        fields:
          - id: bigint
          - name: varchar

      - name: pim_categories
      - name: pim_attributes

    functions:
      - get_product_by_id(id bigint)
      - search_products(query text)
      - update_product_attrs(id bigint, attrs jsonb)

  api:
    type: REST
    endpoints:
      - method: GET
        path: /products
        description: "Список товаров"

      - method: GET
        path: /products/{id}
        description: "Один товар"

      - method: POST
        path: /products
        description: "Создать товар"

  ui:
    type: web_interface
    pages:
      - products-list
      - product-editor
      - brands-management

Использование PIM в pirotehnika

# /L0-ORG/business-units/pirotehnika/connections/pim.yaml
connection:
  name: pim-pirotehnika
  type: service_connection

  service_definition: /PLATFORM/applications/pim

  deployment:
    database:
      instance: /L3-INFRA/database-engines/postgresql-001
      schema: bu_piro              # Схема бизнес-единицы
      prefix: pim_                 # Префикс таблиц

      # Реально созданные таблицы:
      tables:
        - bu_piro.pim_products     # В схеме bu_piro
        - bu_piro.pim_brands
        - bu_piro.pim_categories
        - bu_piro.pim_attributes

    api:
      base_url: https://pim.pirotehnika.internal
      credentials:
        vault_path: /business-units/pirotehnika/connections/pim

    ui:
      url: https://pim.pirotehnika.spb.ru
      access:
        roles:
          - manager       # Полный доступ
          - operator      # Только просмотр и редактирование

15.3. Терминология БД для pirotehnika

Что есть у pirotehnika:

Сервер: postgresql-001                     L3-INFRA (физический сервер)
└── Инстанс: postgres:5432                 L3-INFRA (процесс PostgreSQL)
    └── База данных: postgres              L3-INFRA (catalog, общий)
        └── Схема: bu_piro                 L0-ORG (namespace бизнес-единицы)
            └── Таблицы:                   L0-ORG/services
                ├── pim_products           Префикс pim_ (сервис PIM)
                ├── pim_brands
                ├── pim_categories
                ├── retail_cart            Префикс retail_ (канал retail)
                └── retail_orders

Правильная терминология:

❌ Неправильно ✅ Правильно
"У pirotehnika есть своя база данных" "У pirotehnika есть своя схема (schema) в общей БД"
"PIM использует отдельную базу" "PIM использует таблицы с префиксом pim_ в схеме bu_piro"
"Создать новый инстанс для PIM" "Создать таблицы с префиксом pim_ в существующей схеме"

15.4. Матрица: Определение vs Использование

Аспект Определение (Класс) Использование (Инстанс)
Файл SPECIFICATION.md connection.yaml или index.yaml
Расположение /PLATFORM/applications/{name}/ /L0-ORG/.../connections/{name}.yaml
Описывает Что делает сервис Где и как развернут
Таблицы Список и структура Фактические таблицы в схеме
API Endpoints и методы URL и credentials
UI Страницы и функции URL и права доступа
Переиспользование Многократное Конкретный инстанс

15.5. Работа оператора

Когда оператор работает с PIM:

Оператор открывает UI:
  https://pim.pirotehnika.spb.ru
    ↓
UI подключается к API:
  https://pim.pirotehnika.internal/api/products
    ↓
API читает данные:
  SELECT * FROM bu_piro.pim_products
    ↓
Данные через CONNECTION:
  /L0-ORG/business-units/pirotehnika/connections/pim.yaml
    ↓
Connection ссылается на SERVICE:
  /PLATFORM/applications/pim/

Уровни:
1. L3-INFRA: Физические таблицы bu_piro.pim_products
2. L2-DATA: Коннектор /connections/pim.yaml
3. L1-SERVICE: Определение сервиса /PLATFORM/applications/pim/
4. L0-ORG: Использование в работе operator → UI → API → DATA


СВЯЗИ С ДРУГИМИ ДОКУМЕНТАМИ


Статус: DRAFT
Следующий шаг: Обсудить и утвердить стандарты