product_architecture_strategy_ru

1.

Архитектура продукта
Единый контур: объекты (Inventory) → работы (Tasks/Orders) → контроль → аналитика
Текущее состояние
Цель
• Resource + ResourceSpecification
• Сервис логов
• Базовая FSM
• Минимальный task management
• Актуальный состав оборудования (что/где/когда)
• Управляемые работы: Task / Ticket / WorkOrder
• Controlled change (план→факт→приёмка)
• Сметы/заказы и интеграции с ERP/OSS
Что строим
Платформу управления инфраструктурой и работами: единые данные, единые процессы, контроль качества и стоимости.
Архитектура продукта • v1
2026

2.

Видение: замкнутый цикл управления
Объект → работа → изменение → контроль → экономика
Inventory
(объекты)
Work
(задачи/наряды)
Orders
(сметы/ERP)
Change
(приёмка)
Analytics
(KPI/SLA)
Единые правила, данные и аудит на каждом шаге
Архитектура продукта • v1

3.

База: что уже есть
Отталкиваемся от текущих компонентов
Данные
Процесс
• Resource + ResourceSpecification
• База для развития типов и экземпляров
• Готовность к расширению атрибутов и версий
• Базовая FSM
• Минимальный task management
• Пока нет controlled change в инвентори
Надёжность
Интеграции
• Сервис логов
• Основа для audit/trace
• Нужны outbox + идемпотентность
• Подготовка к ERP/OSS/HR/GIS
• Нужен Integration Hub
• Далее: сверка (drift) с NMS
Архитектура продукта • v1

4.

Область продукта
Домены и зоны ответственности
Platform: Identity • Workflow/FSM • Docs • Notifications • Search • Observability • Integration
Inventory
Work Management
Estimation & Orders
• Объекты: БС/ЦОД/Транспорт
• ЖЦ объектов и оборудования
• Состав: что/где/когда
• Drift и качество данных
• Task (управленческие)
• Ticket (заявки/инциденты + SLA)
• WorkOrder (монтаж/демонтаж)
• Приёмка и доказательства
• Сметы (BOQ, нормы, труд)
• Заказы/заявки в ERP
• Склад/резервы (опц.)
• План‑факт затрат
Архитектура продукта • v1

5.

Ключевые принципы
Чтобы система была управляемой и масштабируемой
Source of Truth
Controlled Change
Event-driven
Workflow Platform
Security
Архитектура продукта • v1
Inventory хранит “как есть”.
WorkOrder → ChangeSet → приёмка → применение.
События + outbox: статусы не теряются.
FSM: версии ЖЦ, guards, policy, audit, available actions.
RBAC/ABAC и изоляция подрядчиков.

6.

Сервисная карта (уровень доменов)
Кто за что отвечает
Engineer UI / Contractor UI / Admin UI → API Gateway + BFF
Platform: Identity • Workflow/FSM • Docs • Notifications • Search • Logs/Audit • Integration Hub
Inventory
Work
Orders
• Catalog (spec)
• Registry (resource)
• Composition/Installation
• Drift/Topology (позже)
• Task
• Ticket + SLA
• WorkOrder + Acceptance
• Routing/Dispatch (опц.)
• Estimation
• Procurement (ERP)
• Stock (опц.)
• План‑факт
Архитектура продукта • v1

7.

Карта микросервисов (целевая)
Группировка по доменам, независимые БД, события
Platform
Inventory
Work
Orders
API Gateway + BFF
Resource Catalog (Spec)
Task
Estimation
Identity & Access
Resource Registry
Ticket + SLA
Cost Catalog
Workflow Platform
Composition/Installation
WorkOrder
Procurement Connector
Docs/Media
Topology (опц.)
Acceptance/Proof
Stock (опц.)
Notifications
Reconciliation (drift)
Dispatch (опц.)
Plan vs Fact
Search
Integration Hub
Архитектура продукта • v1
Каждый сервис владеет своей БД + события

8.

MVP: минимум сервисов без потери архитектуры
Стартуем с ядра и выделяем постепенно
MVP (6–8)
Эволюция
1) API Gateway + 1 BFF
2) Inventory: Spec + Resource + Composition/Install
3) Task+WorkOrder (единый сервис)
4) Workflow/FSM platform (definitions + audit)
5) Documents/Media
6) Notifications
7) Logs/Audit (можно вместе)
8) Integration Hub (заглушки → адаптеры)
• Ticket + SLA отдельным сервисом
• Reconciliation (drift) с NMS/OSS
• Estimation + ERP connector
• Search и BI витрины
• Topology для транспорта
• Dispatch/Routing при росте объёма
Архитектура продукта • v1

9.

Ядро данных инвентори
Spec → Resource → Composition/Installation (что, где, когда)
ResourceSpecification
Resource
Composition / Installation
• тип/модель
• характеристики типа
• версия/validity
• Physical / Logical / Compound
• значения характеристик
• ЖЦ и статусы
• состав (parent→child)
• установка (place/container)
• период действия (from/to)
Пример (БС/ЦОД/Транспорт)
• BaseStation (Compound) → Cabinet → RRU → Antenna (Physical)
• Router (Compound) → Linecards/Ports (Physical/Logical)
• Installation хранит: где стоит, стойка/позиция, даты
• Любое изменение состава — только через WorkOrder/ChangeSet
Архитектура продукта • v1

10.

Workflow/FSM как платформа
Один движок — много процессов (Task, Ticket, Resource, ChangeSet)
Lifecycle Registry
Definitions (versioned)
Runtime
Audit & Outbox
Side-effects
Выбор ЖЦ по контексту (тип/подтип/регион/категория)
States, triggers, transitions, policy, guards
ExecuteAction + GetAvailableActions, идемпотентность, конкуррентность
История переходов + события для слабой связанности доменов
Sync/async actions: уведомления, SLA, ChangeSet, интеграции
Принцип: UI не “угадывает” правила — получает policy + доступные действия из движка.
Архитектура продукта • v1

11.

Контур работ: Task / Ticket / WorkOrder
Три класса задач под одним интерфейсом
Task (управленческая)
WorkOrder (монтаж/демонтаж/замена)
• Руководитель ставит инженеру задачи
• Результаты: комментарии/файлы/проверки
• Может быть привязана к объекту
• Всегда привязан к объекту/оборудованию
• План изменений (ChangeSet Draft)
• Факт + доказательства (Submitted)
• Приёмка инженером → Approved
• Только после Approved можно закрыть наряд
Ticket (инцидент/заявка)
• SLA: реакция/восстановление/закрытие
• Маршрутизация по региону/категории
• Может порождать WorkOrder
WorkOrder → ChangeSet → Apply → Inventory актуален
Архитектура продукта • v1

12.

Интеграции и владение данными
Каждый сервис владеет своей БД, синхронизация через события
Integration Hub
Event Bus + Outbox
• ERP/1C (заказы, бюджеты, статусы)
• NMS/OSS (сверка, состояние, топология)
• HR/контрагенты (пользователи, роли, подрядчики)
• GIS (гео, адреса, карты)
• События доменов: WorkOrder/ChangeSet/Inventory
• Гарантия доставки (outbox)
• Проекции для чтения (read models)
• Минимизация связности между сервисами
Правило владения
• Inventory — источник истины по составу/ЖЦ объектов
• Work — источник истины по процессу и ответственности людей
• Orders — источник истины по сметам/заказам; ERP хранит финансы
• Все изменения фиксируются аудитом и привязаны к наряду/заявке
Архитектура продукта • v1

13.

Roadmap (3–5 лет)
Фундамент → контролируемые изменения → SLA → экономика → качество данных
Этап 0 (0–3 мес)
Inventory core: composition/installation + audit/outbox
Этап 1 (3–9 мес)
WorkOrder + ChangeSet + приёмка + 2 интерфейса
Этап 2 (9–18 мес)
Ticket + SLA + маршрутизация + витрины
Этап 3 (18–30 мес)
Сметы/заказы + ERP интеграции + план‑факт
Этап 4 (30+ мес)
Reconciliation (drift), topology, BI по стоимости/рискам
Архитектура продукта • v1

14.

Эффекты и KPI
Чем измеряем успех продукта
Качество данных
Операции
SLA и экономика
• % объектов без drift
• возраст состава
• % изменений через приёмку
• полнота серийников/атрибутов
• cycle time нарядов
• % возвратов
• загрузка подрядчиков
• причины простоев
• % соблюдения SLA
• MTTR
• % работ со сметой/заказом
• точность план‑факт
Следующий шаг: утвердить MVP (6–8 сервисов) и начать с Inventory composition/installation + WorkOrder/ChangeSet + FSM
platform
Архитектура продукта • v1

15.

Спасибо!
Дальше: детальная ER-модель, контракты API, и MVP план внедрения
Что нужно утвердить
• MVP сервисы и границы владения данными
• Правило controlled change (WorkOrder→ChangeSet →Apply)
• План развития FSM в platform workflow
• Приоритет интеграций (ERP/OSS/HR/GIS)
Архитектура продукта • v1