Архитектура Сервисов Симулятора

Обзор инварианта ядра и сквозная диаграмма последовательности In-Memory взаимодействия

1. Концепция Shared-Инфраструктуры

Архитектурный контур симулятора спроектирован в рамках чистой концепции «черного ящика». Симулятор не дублирует прикладную логику учета, каталоги номенклатур (SKU) или учетные записи пользователей. Вместо этого система разделена на два изолированных домена:

  1. Математический инвариант ядра (In-Memory Core): Вычисляет такты виртуального времени, ведет высокоскоростные карты психологических состояний сотрудников в RAM и рассчитывает векторы интентов. Этот блок неизменен для всей трилогии симуляторов.
  2. Эмулятор действий (User Action Simulator): Единственный прикладной узел, который принимает абстрактный интент ядра, проверяет флаг запуска $simulation\_mode \in \{ \text{home}, \text{enterprise} \}\$ и асинхронно вызывает эндпоинты реального API приложения, полностью имитируя работу живого пользователя в АРМ.

2. Сквозная диаграмма последовательности (Sequence Diagram)

Ниже представлена детальная схема взаимодействия между пятью системно-прикладными сервисами симулятора на протяжении одного внутрисуточной итерации \(t\). Диаграмма наглядно фиксирует, как In-Memory ядро изолировано от дисковых задержек, а маппинг состояний жестко привязан к существующим на бэкенде user_id:

sequenceDiagram
    autonumber
    box RGB(240, 245, 255) In-Memory Ядро Симулятора (RAM)
    participant Core as 🧠 Core Orchestrator
    participant Registry as 👥 Twin Registry (RAM)
    participant Stoch as 🎲 Stochastic Generator
    participant Config as 🎛️ Dynamic Config
    participant Exec as ⛓️ User Action Simulator
    end

    box RGB(255, 245, 240) Целевое Приложение (Черный ящик)
    participant AppAPI as 🚀 Реальный Бэкенд API
    end

    Note over Core, Config: Инициализация такта t виртуального времени
    Core->>Core: execute_intra_day_tick() -> Расчет sim_hour и угловой частоты omega
    
    Core->>Registry: fetch_twin_metrics(user_id)
    activate Registry
    Registry-->>Core: Текущие метки вектора состояний (h_anxiety, m_hunger)
    deactivate Registry

    %% РАСЧЕТ ИНТЕНТОВ
    Core->>Stoch: evaluate_next_step(user_id, current_metrics)
    activate Stoch
    Stoch->>Stoch: Вычисление плотности вероятностей P(t) с учетом циркадного синуса
    Stoch->>Stoch: project_stochastic_seed() -> Метод кумулятивной рулетки (ξ)
    
    alt Штатный шаг симуляции
        Stoch-->>Core: Возврат интента (COOK / CONSUME / INVENTORY)
    else Критический инцидент (Генерация аномалии)
        Stoch->>Stoch: Фиксация ERR-NEGATIVE-ANOMALY
        Stoch-->>Core: Возврат интента: КРИТИЧЕСКИЙ ИНЦИДЕНТ
        
        %% РЕКУРСИВНЫЙ ЦИКЛ МУТАЦИИ
        Note over Stoch, Config: РЕКУРСИЯ: Изменение параметров сессии на лету
        Stoch->>Config: trigger_cascading_failure(user_id)
        activate Config
        Config->>Config: escalate_stress_factors() -> Инкремент h_anxiety (Δ h)
        Config->>Config: execute_affinity_degradation() -> Сброс весов матрицы A_matrix
        Config->>Registry: update_twin_runtime_state(user_id, mutated_fields)
        Config-->>Stoch: Параметры вектора мутировали для такта t + 1
        deactivate Config
    end
    deactivate Stoch

    %% АСИНХРОННОЕ ИСПОЛНЕНИЕ ДЕЙСТВИЯ
    Note over Core, Exec: Исполнение и упаковка транзакции
    Core->>Exec: execute_action_proxy(user_id, intent)
    activate Exec
    
    alt Флаг конфигурации: simulation_mode == home
        Exec->>Exec: dispatch_home_anomaly() -> Сборка DTO (Паника / Компульсивные клики)
    else Флаг конфигурации: simulation_mode == enterprise
        Exec->>Exec: dispatch_enterprise_fraud() -> Сборка DTO (Скрытый фрод / Фиктивное списание)
    end
    
    Note over Exec, AppAPI: Асинхронный пуш DTO (Fire-and-Forget)
    Exec->)AppAPI: POST /api/v1/domain/execute (DTO + user_id)
    
    Exec-->>Core: Шаг эмуляции АРМ завершен успешно
    deactivate Exec

3. Архитектурные преимущества модели

  1. Линейное масштабирование: За счет выноса дисковых IO-Bound операций (запись логов, транзакции СУБД) во внешний контур бэкенда приложения, In-Memory ядро симулятора способно обрабатывать миллионы математических итераций в секунду на хост-машине.
  2. Отсутствие избыточности: Исключение дублирующих микросервисов (Autorization, Inventory, Push) внутри симулятора гарантирует, что бизнес-логика приложения не рассинхронизируется с симуляционным полигоном.
  3. Переиспользуемость (Инвариант): Данная архитектурная схема позволяет симуляторам второй и третьей частей трилогии (AgroLaborApp и Туризм) беспрепятственно использовать этот же пул сервисов, просто расширяя пространство интентов в Stochastic Generator и добавляя при необходимости новые эндпоинты вызовов в User Action Simulator.

sequenceDiagram
    autonumber
    participant Core as 🧠 CoreOrchestrator
    participant Reg as 🗄️ TwinRegistry (RAM)
    participant Stoch as 🎲 StochasticGenerator
    participant Conf as 🎛️ DynamicConfig
    participant Sim as 🚀 UserActionSimulator
    participant API as ⚡ FastAPI Backend
    
    Note over Core: Старт метода orchestrate_next_step() для Пачки из 400 Ботов
    
    %% Запуск параллельного блока
    par Асинхронный конкурентный пул задач (для каждого user_id параллельно)
        
        # 1. Фаза чтения состояния из RAM
        Core->>Reg: registry_fetch_twin_metrics(user_id)
        Reg-->>Core: Текущий числовой вектор состояний двойника
        
        # 2. Фаза инкремента естественного износа/голода
        Core->>Reg: registry_increment_hunger_vector(user_id)
        
        # 3. Фаза стохастического анализа интента
        Core->>Stoch: stochastic_evaluate_next_step(time_context, twin_metrics)
        activate Stoch
        Stoch->>Stoch: stochastic_calculate_intents_density()
        Stoch->>Stoch: stochastic_logistic_normalization()
        Stoch-->>Core: Возврат вычисленного результата (Интент или Аномалия)
        deactivate Stoch
        
        # 4. Ветвление логики: Деструктивное поведение / Мутация или Валидный шаг
        alt Результат == ERR-NEGATIVE-ANOMALY (Критический инцидент)
            Core->>Conf: config_trigger_cascading_failure(user_id)
            activate Conf
            Conf->>Conf: config_escalate_stress_factors()
            Conf->>Conf: config_execute_affinity_degradation()
            Conf-->>Core: Мутированная матрица весов (t + 1)
            deactivate Conf
            
            Core->>Reg: registry_update_twin_runtime_state(user_id, mutated_weights)
            
        else Результат == Валидный интент (например, INVENTORY или SUPPLY)
            Core->>Sim: Метод getStock() или добавление SKU (user_id, token)
            activate Sim
            # Атомарный, но одновременный выстрел в сеть через HTTP/2
            Sim->>API: HTTP GET /api/v1/inventory/stock/{user_id} (или POST)
            API-->>Sim: JSON Response (Индивидуальный цифровой след)
            Sim-->>Core: DTO успешного сетевого шага
            deactivate Sim
        end

    end
    %% Конец параллельного блока
    
    # 5. Фаза сброса состояний (Контур наблюдаемости / Амортизация нагрузок)
    Note over Core, Reg: Окончание такта t. Все асинхронные корутины завершены.
    Core->>Reg: registry_flush_session_states()
    Note over Reg: Буферизированный сброс дельт и логов в СУБД / tracking_event_log

Сквозная диаграмма последовательности рантайм-такта симулятора со всеми системными сервисами