Архитектура, аналитика и лунная база: о чём эта серия

Мысли про архитектуру часто вязнут в двух крайностях. С одной стороны, есть слишком абстрактные разговоры про “правильные паттерны”, где всё выглядит как набор красивых схем без настоящей цены решений. С другой — конкретные истории из реальных проектов, в которых много внутреннего контекста, случайных ограничений и чужой организационной кухни, чтобы из них получалась универсальная рамка мышления.

Эта серия появилась из желания найти третий путь. Такой, где можно говорить о требованиях, аналитике, архитектуре, разработке и эксплуатации как о едином контуре, но без привязки к конкретному корпоративному кейсу. Нужен был пример достаточно сложной системы, чтобы на нём хорошо читались конфликты требований, цена ошибок и роль разных участников. Так возник кейс лунной базы.

Лунная база здесь нужна не как декоративная sci-fi оболочка. Она полезна как мысленный эксперимент, где автономность, задержка связи и цена ошибки делают архитектурные компромиссы видимыми сразу. Если в обычном продукте слабые места можно какое-то время прятать за организационным героизмом или ручными обходами, то в лунной базе почти любой архитектурный самообман быстро становится заметен.

В статье

• Что за лунная база в этой серии
• Почему я не хотел делать ещё одну серию про «идеальные схемы»
• Почему не хотелось брать очередной enterprise-кейс
• Почему лунная база — полезный мысленный эксперимент
• Что именно серия пытается показать
• Маршрут серии и что вы вынесете
• Как её лучше читать

Что за лунная база в этой серии

Чтобы кейс не остался красивой рамкой, зафиксируем границы. Мы рассматриваем постоянную обитаемую базу на 12–24 человека с вахтовой ротацией. Важно сразу развести два объекта: мы не проектируем базу как инженерное сооружение (корпуса, шлюзы, реакторы) — мы проектируем её цифровой контур управления и наблюдения. Именно он — «система» в фокусе серии; саму инженерию жизнеобеспечения мы не изобретаем, а считаем источником требований. В контур входят:

• жизнеобеспечение — воздух, вода, температура, давление: мониторинг и управление;
• энергетика — генерация, накопление, распределение и приоритизация нагрузки;
• связь — канал с Землёй с задержкой и окнами доступности, внутренняя сеть базы;
• снабжение и логистика — запасы, расходники, грузовые миссии, учёт;
• научные эксперименты — полезная нагрузка, сбор и передача данных;
• аварийные и деградационные режимы — что происходит, когда что-то отказывает;
• земной центр управления — внешний участник со своей зоной ответственности.

Сразу оговорюсь: это мысленный эксперимент, а не референсная архитектура NASA или ESA. Я не претендую на точность по физике, регламентам и настоящей космической инженерии — там требования на порядки строже. Лунная база здесь — удобный «стенд», на котором ограничения видны невооружённым глазом, а у решений есть ощутимая цена.

И ещё одна рамка, важная для всей серии: мы смотрим на эту систему глазами разных ролей — аналитика, архитектора, разработчика и инженера эксплуатации. Одна и та же база выглядит по-разному в зависимости от того, кто на неё смотрит, и именно на стыке этих взглядов рождается архитектура.

Чтобы это не было абстракцией, держите в голове один сценарий — мы будем возвращаться к нему всю серию:

Связь с Землёй пропала на 40 минут, а энергобюджет внезапно просел. Нужно решить прямо сейчас и без подсказки с Земли, какие нагрузки отключить, какие данные сохранить, а какие операции отложить.

В этой одной ситуации сходится почти всё: автономность, приоритеты, цена ошибки, деградация и роли тех, кто принимает решение. Если архитектура отвечает на такой сценарий — она рабочая; если нет — это красивая диаграмма.

Почему я не хотел делать ещё одну серию про «идеальные схемы»

Архитектурных материалов много. Но у значительной части из них одна и та же проблема: они слишком быстро переходят к форме решения. Там почти сразу появляются сервисы, очереди, хранилища, event bus, шины интеграции, bounded contexts и deployment diagrams. Всё это может быть полезно, но слишком часто теряется главный вопрос:

Почему система вообще должна принять именно такую форму?

Когда этот вопрос выпадает, архитектура начинает выглядеть как набор канонических приёмов. А потом создаётся ощущение, что хорошее проектирование — это просто умение вовремя выбрать нужный шаблон. На практике всё почти наоборот. Сначала появляется конфликт требований, ограничений, ресурсов и реальных сценариев. И только потом у системы возникает архитектурная форма.

Поэтому серия с самого начала строится не от “идеального решения”, а от ограничений и взаимодействия ролей.

Почему не хотелось брать очередной enterprise-кейс

Можно было бы взять привычный кейс:

• торговую платформу;
• внутреннюю ERP-систему;
• маркетплейс;
• корпоративный документооборот;
• банковский сервис;
• типовую distributed enterprise-систему.

Но у таких кейсов почти всегда есть проблема восприятия. Читатель быстро начинает спорить не с идеей, а с конкретным доменом:

• “у нас в реальности не так”;
• “в нашей компании это делается иначе”;
• “этот пример слишком завязан на конкретный продукт”;
• “здесь организационная проблема, а не архитектурная”.

То есть доменный контекст начинает оттягивать на себя слишком много внимания.

Лунная база в этом смысле удобнее. Она не делает кейс проще, но делает его чище. Меньше случайной корпоративной механики, больше фундаментальных ограничений. И благодаря этому лучше видно, как именно аналитика и архитектура начинают влиять друг на друга.

Почему лунная база — полезный мысленный эксперимент

У хорошего мысленного эксперимента есть одно важное качество: он усиливает существенное и убирает шум.

В лунной базе особенно хорошо видны:

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

То есть здесь почти невозможно притвориться, что:

• требования можно собрать отдельно, а архитектуру придумать потом;
• observability и безопасность можно “добавить в следующем спринте”;
• интеграции — это просто линии между коробками на диаграмме;
• команда разработки сама как-нибудь догадается, что на самом деле имелось в виду.

Лунная база делает эти зависимости очевидными. Именно поэтому она хороша как сквозной кейс.

flowchart TD
  A["Лунная база"] --> B["Ограниченная связь"]
  A --> C["Автономность"]
  A --> D["Энергобюджет"]
  A --> E["Логистика и снабжение"]
  A --> F["Высокая цена ошибки"]
  A --> G["Трудная эксплуатация"]

  B --> H["Асинхронность, очереди, буферизация"]
  C --> I["Локальная автономия и деградация"]
  D --> J["Приоритизация нагрузки (workloads)"]
  E --> K["Доменная модель и процессы"]
  F --> L["Подтверждения, аудит, двухконтурное управление"]
  G --> M["Наблюдаемость и восстановление"]

Что именно серия пытается показать

Главная цель серии — не доказать, что аналитик должен стать архитектором, а архитектор — оператором эксплуатации. Цель другая: показать, что в сложной системе эти роли не могут проектировать по отдельности.

Серия будет возвращаться к нескольким сквозным вопросам:

1. Где требования начинают определять архитектуру? — об этом статьи про роль аналитика и требования как архитектурные драйверы.
2. Как аналитика помогает увидеть архитектурные драйверы раньше, чем появляется схема? — problem statement и метрики и C4-модель для аналитика.
3. Почему доменная модель важнее набора модных терминов? — DDD без культа терминов и как модель ломает и спасает архитектуру.
4. Где инженеры эксплуатации возвращают архитектуру в реальность?
5. Как из этого получается не “идеальная диаграмма”, а рабочая, объяснимая и сопровождаемая система?

Вопросы 4 и 5 — тема следующих статей серии: взаимодействия, согласованность данных, NFR и сквозной итоговый кейс.

Серия про лунную базу на самом деле не про космос. Она про сложные системы вообще.

Маршрут серии и что вы вынесете

Чтобы было видно не только манифест, но и маршрут, вот порядок статей серии:

1. Вводная (эта статья) — кейс, рамки и зачем всё это.
2. Почему аналитику недостаточно только требований — где роль аналитика выходит за сбор хотелок.
3. Problem statement: симптомы, причины и метрики — как корректно поставить задачу до решения.
4. Требования как архитектурные драйверы — как требования и NFR начинают задавать форму системы.
5. DDD для аналитика без культа терминов — доменная модель без моды на термины.
6. Как доменная модель ломает и спасает архитектуру — связь модели с эксплуатацией.
7. C4-модель для аналитика — как схемой думать точнее, а не рисовать красивее.
8. Взаимодействия и интеграции — как части системы и Земля договариваются в условиях задержек.
9. Согласованность данных — где нужна строгая консистентность, а где достаточно «согласуется позже».
10. Эксплуатация в архитектуре — как инженеры эксплуатации возвращают схему в реальность.
11. Сквозной итоговый кейс — собираем всё в одну рабочую, объяснимую и сопровождаемую систему.

Серия делится на две арки: аналитическую (пункты 1–7 — от проблемы и требований к доменной модели и C4) и реализационно-эксплуатационную (пункты 8–11 — взаимодействия, согласованность, эксплуатация и итоговый кейс). Статьи публикуются по расписанию: ссылка становится активной в день выхода, до этого пункт виден, но без перехода — так вы не попадёте на пустую страницу.

После всей серии вы должны унести с собой рабочий набор привычек:

• смотреть на требования и NFR как на архитектурные драйверы, а не как на список пожеланий;
• ставить problem statement до того, как рисовать решение;
• строить и читать C4-модель как инструмент мышления;
• осознанно спорить о границах системы и доменной модели;
• связывать доменную модель с эксплуатацией и деградационными режимами;
• видеть систему глазами разных ролей и понимать, где рождаются дорогие решения.

Как её лучше читать

Серию не обязательно читать по порядку. Каждая статья самостоятельна, но точка входа зависит от роли:

• Аналитику — начать с problem statement и метрик и требований как архитектурных драйверов. Это про то, где аналитика перестаёт быть сбором хотелок и начинает влиять на форму системы.
• Архитектору — с DDD без культа терминов и C4-модели. Это про то, как модель и схема помогают думать точнее, а не рисовать красивее.
• Разработчику или тимлиду — с роли аналитика и как модель ломает архитектуру. Это про то, где дорогие технические решения на самом деле рождаются задолго до кода.

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