Вся серия строилась вокруг одного сквозного сценария: связь с Землёй пропала на 40 минут, а энергобюджет просел. Мы рассматривали его по частям — с точки зрения постановки проблемы, требований, доменной модели, схем, взаимодействий, согласованности и эксплуатации. В этой, финальной статье соберём всё вместе и пройдём сценарий целиком: от первого вопроса аналитика до поведения системы в момент аварии и после неё.
Цель — не показать «единственно правильную архитектуру лунной базы» (её не существует), а продемонстрировать, как связаны решения. Каждый слой опирается на предыдущий, и пропуск любого из них ломает результат.
В статье
- Шаг 1. Problem statement и метрики
- Шаг 2. Требования как драйверы
- Шаг 3. Доменная модель и границы
- Шаг 4. Архитектурная форма на C4
- Шаг 5. Взаимодействия и согласованность
- Шаг 6. Эксплуатация: проживаем аварию
- Что связывает всё вместе
- Чему учит вся серия
Шаг 1. Problem statement и метрики
Начинаем не с решения, а с точной постановки (как в статье про problem statement).
- Симптом: во время разрыва связи экипаж жалуется, что система тормозит с подтверждением операций.
- Хороший problem statement: при потере связи с Землёй (до 40 минут) часть критичных для жизнеобеспечения операций ждёт подтверждения наземного контура, что задерживает решения экипажа в момент дефицита энергии и повышает риск.
- Метрика + порог: 100% операций из перечня критичных для жизнеобеспечения исполняются локально; подтверждение ≤ 1 с при недоступном канале. Сам перечень критичных операций утверждён отдельно и версионируется — это не «критичные по ощущениям», а согласованный и поддерживаемый список.
Уже здесь видно: проблема не в «скорости», а в зависимости критичного решения от внешнего контура.
Шаг 2. Требования как драйверы
Из постановки вырастают архитектурные драйверы:
| Требование | Почему драйвер | Что меняет |
|---|---|---|
| Критичные операции — локально при потере связи | нельзя ждать внешний контур | локальный контур решений, классификация операций |
| Жизнеобеспечение сохраняется при просадке энергии | энергия — жёсткое ограничение | приоритизация нагрузок, деградация |
| Решения восстановимы и объяснимы | нужен разбор после аварии | журнал решений, синхронизация позже |
Шаг 3. Доменная модель и границы
Драйверы требуют точной модели (без культа терминов и без ложного обобщения). «Ресурс на всё» здесь смертельно опасен: в момент аварии система обязана различать аварийный резерв кислорода и складской буфер запчастей.
Поэтому вместо универсального Resource — раздельные понятия с разными правилами: резерв жизнеобеспечения, энергобюджет, складской запас, робот-актив.
Отсюда и границы контекстов: жизнеобеспечение, энергетика, логистика, локальные решения, синхронизация с Землёй.
Шаг 4. Архитектурная форма на C4
Модель ложится на C4-уровни:
- Context: при потере связи наземный центр временно недоступен — решение остаётся между экипажем и системой базы.
- Container: контур локальных решений, жизнеобеспечение, энергетика, логистика, контур синхронизации с Землёй.
- Component: внутри контура решений — классификатор критичности операций, политика деградации, журнал, приоритизация потребителей энергии.
flowchart TD
crew["Экипаж"] -->|критичная операция, sync| dec["Контур локальных решений"]
dec -->|приоритеты| energy["Энергетика"]
dec -->|пороги, резервы| life["Жизнеобеспечение"]
dec -->|что отложить| log["Логистика"]
dec -->|фиксирует| jrn["Журнал решений"]
dec -.->|буфер до связи| sync["Синхронизация с Землёй"]
sync -.-> ground["Наземный центр (недоступен 40 мин)"]
Шаг 5. Взаимодействия и согласованность
Каждая связь получает свой контракт (взаимодействия и согласованность):
- критичная операция жизнеобеспечения — синхронно, локально, строгая согласованность, без выхода на Землю;
- энергобюджет — локально, строгая согласованность, пересчёт приоритетов на месте;
- команды с Земли — async, буфер до связи, идемпотентность, TTL / valid-until, исполняются только если ещё актуальны и не конфликтуют с локальными решениями;
- телеметрия — поток событий в очередь с приоритетами, eventual: догоняет Землю после связи;
- аналитика — пакетная, может отстать или не выполниться, это допустимо.
Здесь нет ни одной «просто стрелки»: у каждой — обещание, гарантия и поведение при разрыве.
Шаг 6. Эксплуатация: проживаем аварию
И наконец система должна это пережить эксплуатационно. Хронология аварии:
- Связь пропала. Контур синхронизации переходит в буферный режим; критичные решения продолжают исполняться локально.
- Энергобюджет просел. Деградация по уровням: некритичные нагрузки понижаются, жизнеобеспечение сохраняется; система явно сообщает экипажу о переходе в аварийный режим.
- Экипаж принимает решения на основе локально видимой картины (пороги, энергобаланс); каждое решение фиксируется в журнале.
- Связь восстановилась. Буферизованные команды Земли проверяются на актуальность (TTL) и применяются идемпотентно; телеметрия догоняет наземный центр; система выходит из деградации по короткой процедуре восстановления (runbook) — в заданном порядке, а не лавиной отложенных операций.
- Разбор. По журналу решений наземный центр восстанавливает, что произошло и почему.
Сценарий пройден без потери жизнеобеспечения и без зависимости критичных решений от связи — потому что это было заложено на каждом из предыдущих шагов.
Что связывает всё вместе
Главное наблюдение финала: ни один слой не работает в одиночку.
- Уберите точный problem statement — и драйверы будут отвечать не на ту задачу.
- Уберите требования-драйверы — и архитектурные решения потеряют критерии выбора.
- Уберите различение в доменной модели — и в момент аварии система не отличит аварийный резерв от склада.
- Уберите контракты взаимодействий — и стрелки снова станут догадками, а потеря связи обрушит критичное.
- Уберите осознанный выбор согласованности — и критичное решение зависнет в ожидании Земли.
- Уберите эксплуатируемость — и красивая архитектура рассыплется при первом инциденте.
+ метрики"] --> B["Требования-драйверы"] B --> C["Доменная модель
и границы"] C --> D["C4: форма системы"] D --> E["Взаимодействия
и согласованность"] E --> F["Эксплуатация
и деградация"] F -->|разбор и обратная связь| A
flowchart LR
A["Problem statement
+ метрики"] --> B["Требования-драйверы"]
B --> C["Доменная модель
и границы"]
C --> D["C4: форма системы"]
D --> E["Взаимодействия
и согласованность"]
E --> F["Эксплуатация
и деградация"]
F -->|разбор и обратная связь| A
Обратите внимание на стрелку обратной связи: эксплуатация возвращает уроки в постановку проблемы. Архитектура — не разовый акт, а цикл.
Чему учит вся серия
Если свести серию к нескольким принципам:
- Сначала задача, потом форма. Архитектура рождается из точной постановки и измеримых требований, а не из выбора технологии.
- Различия важнее обобщений. И в доменной модели, и в данных, и во взаимодействиях ценно ровно то, что нельзя свести к «универсальному».
- Роли проектируют вместе. Аналитик, архитектор, разработчик и эксплуатация видят одну систему по-разному — и архитектура рождается на стыке их взглядов.
- Эксплуатируемость — часть архитектуры. Система живёт настолько, насколько её можно наблюдать, деградировать и восстанавливать.
На этом серия про лунную базу завершается. Она была не про космос, а про сложные системы вообще — про то, как из проблемы, требований и ролей рождается рабочая, объяснимая и сопровождаемая архитектура.
Комментарии