Skip to content

Terry Prototype History

Context

До появления Terry существовал более ранний прототип платформы под названием Maggie. Эти артефакты полезны как historical lineage: они показывают, что у Terry уже был предшественник с config-driven ingestion, orchestration, raw/structured storage и notifications.

Эти файлы не являются текущим source of truth для реализации Terry, но их стоит учитывать как reference material при проектировании runtime, contracts и migration narrative.

Prototype Artifacts

Все historical artifacts теперь сохранены внутри репозитория в docs/terry/prototypes/.

Process diagrams

По содержимому Visio-диаграммы видно, что Maggie уже моделировала:

  • Web-API Module
  • Job Module
  • Data Source Module
  • Loader Module
  • Raw Data Store Module
  • Data Processor Module
  • Structured Data Store Module
  • Notification Module
  • Шина данных

Также диаграмма фиксирует важные orchestration concepts, которые напрямую перекладываются на Terry:

  • запуск pipeline через UI или API;
  • формирование job instance;
  • получение source configuration из отдельного data source модуля;
  • загрузка сырых данных, дедупликация по hash и управление retention;
  • freshness/validation checks;
  • transformation и сохранение structured data;
  • генерация и доставка notifications;
  • явные job statuses и error/result codes.

Data source configuration prototypes

Оба файла подтверждают, что прототип уже был декларативным:

  • domain и codeName описывали ownership источника;
  • loader задавал transport details, включая SOAP operation, URL и parameters;
  • dataTransformer задавал transformer_xslt и XSL template;
  • dataSourceFields описывали mapping из expression/source fields в structured fields.

Для Terry это важный сигнал: configuration model не стоит придумывать с нуля, нужно сохранить continuity между Maggie prototype и Terry docs, особенно в терминах source, loader, transformer, field mapping.

API coverage inventory

По имени и формату это выглядит как учётный артефакт по покрытию или описанию API методов. Даже без включения его в репозиторий Terry стоит трактовать такие файлы как:

  • inventory источников и методов;
  • backlog для будущих source adapters;
  • материал для prioritization в roadmap.

Rule editor prototype

Из приложенного UI screenshot видно, что прототип уже поддерживал:

  • редактирование имени и описания правила;
  • expression-based rule definition;
  • group by semantics;
  • дополнительные источники;
  • каталог операций и функций;
  • привязку выражений к structured fields, включая cbrf_exchangeRates.CharCode и cbrf_exchangeRates.Value.

Это напрямую подтверждает Terry requirement на:

  • rule engine поверх normalized data;
  • expression language с function library;
  • multi-source correlation;
  • template-driven notification trigger model.

Mapping Maggie -> Terry

Ниже практическое соответствие между старым прототипом и текущей Terry vocabulary:

  • Maggie Data Source Module -> Terry source + source configuration
  • Loader Module -> Terry ingestion adapter / loader
  • Data Processor Module -> Terry validation + transformation layers
  • Raw Data Store Module -> Terry raw payload storage
  • Structured Data Store Module -> Terry sink / normalized record persistence
  • Notification Module -> Terry notification engine + delivery channels
  • Job Module -> Terry orchestration / job runner
  • шина данных -> Terry async execution backbone

How To Use These Artifacts

  • использовать их как legacy reference, а не как final spec;
  • переносить из них устойчивые domain ideas, а не implementation noise;
  • сверять Terry ERD и configuration model с тем, что уже было опробовано в Maggie;
  • фиксировать divergence явно, если Terry сознательно отходит от старого прототипа.

Documentation Policy

Canonical copy этих прототипов теперь хранится рядом с Terry docs, а внешний iCloud location можно считать только исходным источником.

При этом сами артефакты всё равно нужно трактовать как legacy reference: Terry docs должны пересказывать только те решения, которые реально влияют на текущую архитектуру.