Termins

Giga,

https://giga.chat/link/gcsNsURjkh

Single Source of Truth (Единый источник истины) 

Принцип, согласно которому каждый фрагмент данных в системе хранится и изменяется только в одном месте. Все остальные части системы получают эти данные по ссылке или через копирование, но никогда не редактируют их локально. Это исключает рассинхронизацию: если адрес клиента изменился в профиле, он автоматически обновился везде.

i18n (Internationalization — Интернационализация) 

Технический процесс подготовки приложения к адаптации под разные языки и регионы без изменения исходного кода. Включает вынос всех строковых констант во внешние файлы локализации, поддержку Unicode (UTF-8) и отделение логики отображения дат, валют и чисел от бизнес-логики. Следующий шаг после i18n — L10n (локализация), то есть сам перевод на конкретный язык.

CRUD + Safety 

Расширение классической модели работы с данными (Create, Read, Update, Delete) добавлением механизмов обеспечения целостности. В отличие от «голого» CRUD, здесь каждая операция защищена:

• Версионирование: для оптимистической блокировки конфликтов при одновременном редактировании.
• Мягкое удаление (Soft Delete): вместо физического удаления ставится отметка is_deleted.
• Аудит: запись того, кто и когда изменил строку. Это превращает базу данных из простого хранилища в надежный журнал событий.

Half-life of Knowledge (Период полураспада знаний) 

Концепция, описывающая устаревание информации. Это время, за которое половина полученных вами фактов или навыков становится неактуальной или ошибочной из-за развития технологий. Для разработчика это означает необходимость постоянного переобучения: знания о конкретном фреймворке трехлетней давности сегодня могут стоить вдвое меньше.

Экзокортекс (Exocortex) 

Термин из киберпанка, означающий внешнюю систему расширения когнитивных способностей человека. В современном контексте это связка ваших цифровых инструментов (заметки второго мозга вроде Obsidian, менеджер задач, база знаний), которая берет на себя хранение контекста, связей между идеями и напоминания, разгружая ваш биологический мозг для чистого мышления.

LangChain 

Фреймворк для создания приложений на базе больших языковых моделей (LLM). Он позволяет соединять модель в цепочки (chains): например, сначала взять вопрос пользователя, превратить его в запрос к поисковику, получить текст статьи, передать этот текст модели для суммаризации и выдать ответ. Инструмент для построения сложных агентов вокруг нейросетей.

Скорость прототипирования (Velocity of Prototyping) 

Метрика, показывающая, как быстро команда может пройти путь от идеи до работающего черновика продукта. Высокая скорость достигается за счет использования готовых библиотек, конструкторов интерфейсов и отказа от написания идеальной архитектуры на старте в пользу принципа «сделать криво, но завтра».

Фокус на метаданных (Metadata-driven approach) 

Архитектурный подход, при котором логика системы определяется не жестким кодом, а конфигурацией (данными о данных). Вместо десяти функций ProcessXml, ProcessJson, ProcessCsv пишется один универсальный движок, который читает описание формата из таблицы БД (метаданные) и обрабатывает файл динамически.

Antifragility (Антихрупкость) 

Свойство систем, которые не просто выдерживают хаос и стрессовые факторы (как устойчивые/robust системы), а становятся от них сильнее и лучше. Пример в ИТ: распределенная система, которая при падении одного узла перенаправляет трафик, заставляя администраторов заметить узкое место и проактивно увеличить мощность кластера еще до катастрофы.

Графовые базы данных (Graph Databases) 

Тип СУБД, где основным способом хранения являются узлы (вершины) и связи (ребра) между ними. Они спроектированы так, чтобы мгновенно выполнять обходы связей любой глубины (например, «найти друзей друзей друзей»), что крайне медленно работает в классических реляционных базах из-за тяжелых операций JOIN.

Property Graphs (Атрибутированные графы) 

Самый распространенный подвид графовых баз данных. В таких моделях и узлы, и ребра могут хранить произвольные пары «ключ-значение» (свойства/атрибуты).

• Узел Пользователь имеет свойства {name: "Иван", age: 30}.
• Ребро КУПИЛ_У между Иваном и Магазином имеет свойство {date: "2025-10-01"}

Shared Fate

Shared Fate

https://giga.chat/link/gcskZAXFLs

Английское наименование: Shared Fate (Общая судьба).

Русская трактовка: Это концепция из области проектирования отказоустойчивых распределенных систем, которая описывает ситуацию, когда несколько независимых компонентов системы настолько тесно связаны или зависят друг от друга, что сбой одного компонента неизбежно и практически мгновенно приводит к неработоспособности всей группы.

В отличие от принципа «отсутствия единой точки отказа» (No Single Point of Failure), где компоненты изолированы, архитектура с «общей судьбой» подразумевает наличие скрытого общего ресурса или условия, гибель которого убивает всех его потребителей одновременно.

Механика возникновения

«Общая судьба» обычно возникает в одной из трех ситуаций:

1. Общий скрытый ресурс. Компоненты кажутся независимыми, но используют одну базу данных, один файловый диск или один канал связи. Если падает база — падают все сервисы, даже если их вычислительные мощности исправны.
2. Каскадный сбой (Cascading Failure). Один компонент перегружается и начинает отвечать медленно. Его клиенты (другие компоненты) ждут ответа, занимая свои потоки. Вскоре у клиентов заканчиваются ресурсы (память, CPU, свободные нити), и они тоже начинают падать или тормозить. Смерть распространяется как вирус.
3. Жесткая синхронизация. Компоненты должны работать строго согласованно (например, через протокол консенсуса вроде Raft). Если большинство узлов выходит из строя или теряет связь между собой, вся система останавливает запись данных, чтобы избежать расщепления мозга (split-brain). Судьба записи зависит от судьбы большинства.

Отличие от Изоляции (Isolation)

Чтобы лучше понять «Общую судьбу», полезно сравнить ее с противоположным подходом:

Характеристика	Общая судьба (Shared Fate)	Изоляция / Отказоустойчивость
Связь	Жесткая зависимость (High Coupling)	Слабая связь (Loose Coupling)
Реакция на сбой	Каскадное падение всей системы	Деградация (один модуль упал, остальные работают)
Пример	Все микросервисы подключены к одному экземпляру PostgreSQL без реплик.	Каждый сервис имеет свою БД или доступ к кластеру с автоматическим переключением мастера.
Философия	«Мы либо работаем вместе, либо умираем вместе».	«Я могу выжить, даже если мой сосед сгорел».

Почему это опасно?

Главная проблема «Общей судьбы» — эффект домино. Ошибка в одном некритичном модуле может обрушить критически важную часть бизнеса. Кроме того, такие системы крайне сложно тестировать на устойчивость (Chaos Engineering), так как нужно ломать именно общий фундамент, а не отдельные надстройки.

Как бороться с «Общей судьбой» в вашей архитектуре

Ваша текущая модель с FractalCellTemplate, BehaviorRouter и очередями уже содержит инструменты для минимизации общей судьбы:

1. Бюджетирование ошибок (Error Budgets) и Цепи размыкания (Circuit Breakers): Если одно поведение (PaymentBehavior) начало постоянно падать, оно не должно блокировать весь конвейер. Circuit Breaker вокруг этого поведения разомкнется, отсекая его от шины. Остальные поведения продолжат работу. Это разрывает общую судьбу ячейки и конкретного хендлера.
2. Изоляция ресурсов: Каждое поведение или группа поведений должна иметь свой ограниченный пул потоков или токенов пропускной способности. Если DataProcessingBehavior ушел в бесконечный цикл, он сожжет только свои токены, не заблокировав выполнение HeartbeatBehavior.
3. Отсутствие разделяемого изменяемого состояния (Shared Mutable State): Использование неизменяемых сообщений во InternalBus гарантирует, что одно поведение не сможет испортить данные в памяти, которые читает другое поведение.
4. Таймауты: Стратегия ILivenessStrategy, о которой мы говорили, по сути является механизмом выхода из «общей судьбы» зависимостей. Если внешняя БД стала недоступна, ячейка не ждет вечно (разделяя её судьбу), а признает себя неживой и перезапускается.