Итоговый проект: архитектурный пакет для обезличенной системы

Проект делается дважды. Первая версия — после этапа 1 (недели 11–12), на знаниях блоков 1–3. Вторая — в конце программы: тот же пакет дорабатывается инструментами этапа 2 (атрибуты качества и ADR, C4 и arc42, развёртывание, DR, стоимость, ИИ-функция) и становится портфолио для собеседований.

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

Готовность к модулю

Модуль опирается на темы ниже. Если какая-то из них незнакома или её вопросы для самопроверки даются с трудом, начните с неё.

Выбор домена

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

  • интернет-магазин с резервированием товара, оплатой и доставкой;
  • автоматическое пополнение запасов сети магазинов: прогноз → заказ поставщику → приёмка;
  • дистанционное банковское обслуживание юрлиц: платёжное поручение → проверки → исполнение → выписка;
  • маркетплейс доменных имён: аукцион → оплата → трансфер.

Что сделать

Каждый пункт — отдельный раздел в 04-capstone/ (markdown + диаграммы в mermaid или PlantUML).

  1. Контекст и цели (1 страница): что делает система, ключевые сценарии, 5–7 нефункциональных требований с числами (нагрузка, время ответа, доступность, RPO / RTO).
  2. Доменная модель (3.2): результаты Event Storming, поддомены с классификацией, ограниченные контексты, карта контекстов с типами отношений.
  3. Решение о декомпозиции (3.1): микросервисы, модульный монолит или гибрид — оформить как ADR (Architecture Decision Record): контекст, варианты, решение, последствия.
  4. Схема развёртывания (3.3): клиенты, L4 / L7, gateway, BFF, сервисы, брокер, базы. Где терминируется TLS, где проверяется токен.
  5. Интеграции (блок 1, 3.4): OpenAPI на внешний API (с идемпотентностью, ошибками, пагинацией), AsyncAPI на ключевые события, схема аутентификации и авторизации, чек-лист OWASP API Top 10.
  6. Сквозной процесс (3.5): сага с компенсациями, pivot, Outbox, конечный автомат статусов, таблица отказов.
  7. Данные (блок 2): модель данных одного сервиса, инварианты и механизмы их защиты (уровень изоляции, блокировки, ограничения), индексы под ключевые запросы, план одной миграции без простоя, требования к репликам и отставанию.
  8. Устойчивость и наблюдаемость (3.6, 3.7): таблица политик для внешних вызовов, SLO, бизнес-метрики, алерты.
  9. Риски и открытые вопросы: что осталось нерешённым и почему.

Вторая версия: что добавить после этапа 2

  • Цели качества в виде сценариев и дерево полезности (6.1); все ключевые решения — в формате ADR (6.2).
  • Диаграммы C4 уровней 1–2 и документ по сокращённому arc42 (6.3); анализ компромиссов по одному спорному решению (6.4).
  • Оценки нагрузки и объёмов, узкие места и масштабирование в формате System Design (7.2, 7.4).
  • Одна ИИ-функция в системе, оформленная по шаблону постановки (5.7).
  • Карта интеграций со стилями, гарантиями и сверками (блок 8); аналитический контур (блок 9).
  • Развёртывание, стратегия релизов, план DR с RPO/RTO и стоимость инфраструктуры (блок 10).
  • Рассказ о проекте на 5 минут для собеседования (11.5).

Как проверить

  • Попросить знакомого архитектора или разработчика провести по пакету ревью в формате собеседования: «почему так, а не иначе?».
  • Либо провести ревью с Claude в отдельной сессии: дать пакет и попросить задавать вопросы как интервьюер уровня senior / lead, не подсказывая ответы.
  • Каждый вопрос, на который не нашлось хорошего ответа, — повод вернуться к соответствующему модулю.

Критерий готовности

Пакет можно за 20–30 минут рассказать на собеседовании, и на любой вопрос «почему» есть обоснование с компромиссами.