Перейти к содержанию

ADR 0102: Data Acquisition Layer — граница внешних интерфейсов и адаптеров

Статус: Accepted
Дата: 2026-04-26

Связанные ADR

ADR Роль
0006 связанный ADR
0008 связанный ADR
0009 связанный ADR
0094 связанный ADR
0095 связанный ADR
0097 связанный ADR
0099 связанный ADR

Резюме

  • DAL — явная граница добычи внешних данных.
  • Контракт DAL ↔ CCU ↔ UI; сырой I/O не в VM.

1. Контекст

В кодовой базе есть вычислительные юниты (CCU), orchestration в MainWindowViewModel и набор сервисов/адаптеров, которые читают внешние источники (файлы, процессы, конфиги, wire payload).
Без отдельного каноничного термина и границы этот внешний слой «расползается» по Services, ViewModels, а иногда попадает в ComputingUnits.

Это создаёт дрейф:

  • CCU начинают смешиваться с IO;
  • сложно автоматически проверять границы анализаторами;
  • растёт связность и стоимость рефакторинга.

2. Решение

Ввести и закрепить единый термин: Data Acquisition Layer (DAL).

DAL — слой внешних интерфейсов для вычислительного контура: входящий сбор/чтение и исходящая передача данных наружу.

В DAL входит

  • fs операции (File, Directory, проверка существования, пути);
  • запуск внешних процессов и сбор их вывода;
  • parse/serialize внешних форматов (json, toml, wire payload);
  • интеграционные резолверы и адаптеры источников.
  • исходящая передача наружу (запись, отправка, внешние вызовы), где это требуется фичей.

В DAL не входит

  • вычисление смысловых snapshot/DTO канала;
  • UI-рендер и UI-композиция;
  • маршрутизация слотов/поверхностей.

3. Граница с CCU и UI

  • DAL: добывает и нормализует внешние данные.
  • CCU (Cockpit/ComputingUnits/*): считает смысловые snapshot/DTO из уже подготовленного входа.
  • CDS/UI: отображают готовые снимки.

Инвариант:

  1. CCU не выполняет прямых внешних вызовов (ни inbound, ни outbound).
  2. DAL не подменяет собой CCU-композицию канала.
  3. MainWindowViewModel не становится местом массовой добычи данных из внешнего мира.

4. Размещение кода (strangler)

Базовое размещение DAL:

  • Features/<Feature>/DataAcquisition/*

Соседний слой для orchestration/use-case логики:

  • Features/<Feature>/Application/*

Разделение ответственности:

  • DataAcquisition — адаптеры внешнего мира (I/O, process, wire, API).
  • Application — подготовка use-case payload/правил сценария без прямых внешних вызовов. Для классов оркестрации рекомендуется явный нейминг *Orchestrator.
  • CCU — вычисление смысловых snapshot/DTO канала.

На переходном этапе допустимы узкие адаптеры в Services/*, если:

  • есть явный интерфейс;
  • слой не тянет UI;
  • есть план переноса в feature-инфраструктуру.

5. Пример первого среза

Launch-контур:

  • LaunchProfilesStore и LaunchSettingsJsonImport относятся к DAL;
  • LaunchReadinessUnit, LaunchPreResolvePipelineUnit, LaunchProfileProjectResolveUnit остаются в CCU;
  • MainWindowViewModel выполняет orchestration.

6. Проверка границ

Для DAL/CCU вводятся архитектурные guardrails (CASCOPE*):

  • запрет IO/process/wire parse в Cockpit/ComputingUnits/*;
  • запрет зависимостей CCU на ViewModels/Views/Ui*;
  • поэтапный rollout: warning -> baseline cleanup -> error.

7. Последствия

  • Граница «добыча данных vs вычисление смысла» становится явной.
  • Рефакторинг Services в feature-срезы становится детерминированным.
  • Анализаторы получают однозначную цель для правил.

8. Не цели

  • Big-bang перенос всех Services/* в один коммит.
  • Принудительный rename всех существующих namespace за один этап.
  • Изменение контракта DataBus этим ADR.