Вся серия строилась вокруг одного сквозного сценария: связь с Землёй пропала на 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: догоняет Землю после связи;
- аналитика — eventual consistency с пакетной синхронизацией: может отстать или не выполниться, это допустимо.
Здесь нет ни одной «просто стрелки»: у каждой — обещание, гарантия и поведение при разрыве.
Шаг 6. Эксплуатация: проживаем аварию
И наконец система должна это пережить эксплуатационно. Хронология аварии:
- Связь пропала. Контур синхронизации переходит в буферный режим; критичные решения продолжают исполняться локально.
- Энергобюджет просел. Деградация по уровням: некритичные нагрузки понижаются, жизнеобеспечение сохраняется; система явно сообщает экипажу о переходе в аварийный режим.
- Экипаж принимает решения на основе локально видимой картины (пороги, энергобаланс); каждое решение фиксируется в журнале.
- Связь восстановилась. Буферизованные команды Земли проверяются на актуальность (TTL) и применяются идемпотентно; телеметрия догоняет наземный центр; система выходит из деградации по короткой процедуре восстановления (runbook) — в заданном порядке, а не лавиной отложенных операций.
- Разбор. По журналу решений наземный центр восстанавливает, что произошло и почему.
Сценарий пройден без потери жизнеобеспечения и без зависимости критичных решений от связи — потому что это было заложено на каждом из предыдущих шагов.
Артефакты кейса: что остаётся на руках
Шаги выше — это ход рассуждения. Но архитектура жива только тогда, когда оставляет артефакты, с которыми потом работают разработка и эксплуатация. Именно они отличают «нарисовали систему» от «собрали рабочую». Покажем три, вырастающих прямо из нашего сценария.
Решение как запись (decision log)
Ключевые решения фиксируются коротко и одинаково — чтобы через год или в разборе аварии было понятно не только что решили, но почему и что отвергли:
ADR-004. Критичные операции жизнеобеспечения исполняются локально Контекст. Связь с Землёй пропадает до 40 минут; критичные для жизни операции не могут ждать наземного подтверждения. Решение. Локальный контур решений; перечень критичных операций классифицирован и версионируется; наземное подтверждение — только для некритичных. Последствия. (+) выживание не зависит от связи; (−) нужны локальная согласованность, журнал и последующая синхронизация; (−) приходится поддерживать классификатор критичности. Альтернативы (отвергнуты). Ждать Землю с таймаутом — риск для жизни в окне разрыва. Дублировать наземный центр на базе — дорого и всё равно требует локального арбитра.
Одна запись на решение — а через год их набор объясняет форму системы лучше любой схемы.
Паспорт одной стрелки (контракт)
Каждая связь на C4-схеме — это контракт, а не линия. Вот «паспорт» самой коварной стрелки — команды с Земли:
| Поле | Значение |
|---|---|
| Направление | наземный центр → контур решений базы |
| Тип | команда (намерение изменить), не событие |
| Синхронность | async, буфер до восстановления связи |
| Гарантия доставки | at-least-once + идемпотентность (повтор безвреден) |
| Актуальность | valid-until (TTL) + ожидаемая версия состояния |
| Поведение при разрыве | буферизуется; при восстановлении применяется, только если не протухла и не конфликтует |
| При конфликте | не перезатирает локальное решение — уходит на reconciliation |
Так «просто стрелка» превращается в проверяемое на ревью обещание.
Хронология аварии (sequence)
И, наконец, шаг 6 как поток, а не список: кто, кому и что шлёт за 40 минут разрыва — от потери связи до reconciliation конфликтующей команды Земли.
sequenceDiagram
participant C as Экипаж
participant D as Контур решений
participant L as Жизнеобеспечение
participant E as Энергетика
participant J as Журнал
participant S as Синхр. с Землёй
Note over D,S: t0 — связь пропала
S->>D: переход в буферный режим
Note over E: t0+5 — энергобюджет просел
E->>D: энергобаланс ниже порога
D->>E: понизить некритичные нагрузки
D->>L: сохранить жизнеобеспечение
C->>D: критичная операция (локально)
D->>J: зафиксировать решение (v42)
Note over D,S: t0+40 — связь восстановилась
S->>D: буфер: команда Земли (valid-until t0+30, ждёт v41)
D->>D: протухла по TTL и v41≠v42 → на reconciliation
D->>S: телеметрия и журнал догоняют Землю
Три артефакта — decision log, паспорт стрелки и хронология — это то, что можно передать разработке, проверить на ревью и достать в момент инцидента. Без них шаги 1–6 остаются убедительным рассказом; с ними — рабочей системой.
Что связывает всё вместе
Главное наблюдение финала: ни один слой не работает в одиночку.
- Уберите точный 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
Обратите внимание на стрелку обратной связи: эксплуатация возвращает уроки в постановку проблемы. Архитектура — не разовый акт, а цикл.
Чему учит вся серия
Если свести серию к нескольким принципам:
- Сначала задача, потом форма. Архитектура рождается из точной постановки и измеримых требований, а не из выбора технологии.
- Различия важнее обобщений. И в доменной модели, и в данных, и во взаимодействиях ценно ровно то, что нельзя свести к «универсальному».
- Роли проектируют вместе. Аналитик, архитектор, разработчик и эксплуатация видят одну систему по-разному — и архитектура рождается на стыке их взглядов.
- Эксплуатируемость — часть архитектуры. Система живёт настолько, насколько её можно наблюдать, деградировать и восстанавливать.
На этом серия про лунную базу завершается. Она была не про космос, а про сложные системы вообще — про то, как из проблемы, требований и ролей рождается рабочая, объяснимая и сопровождаемая архитектура.
См. также
- Архитектура, аналитика и лунная база: о чём эта серия
- Эксплуатация в архитектуре: как инженеры возвращают схему в реальность
- C4-модель для аналитика
- Внешнее: Simon Brown — C4 model (нотация уровней), Eric Evans — «Domain-Driven Design» и Vaughn Vernon — «Implementing Domain-Driven Design» (границы контекстов, агрегаты), architecture decision records (ADR) (формат decision log).
Комментарии