В презентации технической архитектуры покажите три вещи по порядку: место системы в окружении, путь одного важного запроса и причины, по которым предложенный вариант лучше альтернатив. В конце сформулируйте решение, которое нужно принять. Схема компонентов сама по себе не объясняет ни поведение системы, ни компромиссы.
Пример ниже посвящён сервису заказов вымышленной розничной компании. Команда рассматривает очередь между приёмом заказа и его выполнением. Презентация должна помочь разработке и эксплуатации решить, стоит ли запускать пилот такого изменения. Это не проект реальной системы для промышленной эксплуатации.
Когда схемы и сравнение готовы, превратите план архитектурной презентации в редактируемые слайды с Presenti. Передайте в исходном тексте техническую логику: тогда первый черновик сможет выстроить полезный рассказ, а не придумывать устройство системы.
Назовите изменение, которое предлагаете принять
Запишите решение до создания первого слайда: «Одобрить пилот асинхронного выполнения принятых заказов, сохранив авторизацию платежа в текущем потоке». Сразу обозначьте границы: интеграция с платёжным провайдером, замена базы данных и полный пересмотр оформления заказа в эту дискуссию не входят.
Эта формулировка определяет нужную глубину рассказа. Руководителю эксплуатации важно понять, как выглядит задержка задания на выполнение заказа. Руководителю разработки — как обрабатываются повторы и дубликаты. Ни тому ни другому не нужен обзор каждого сервиса компании. Если ожидаемое поведение пользователя ещё вызывает споры, согласуйте его в презентации требований к продукту, прежде чем выбирать архитектуру на этой встрече.
Начните с окружения системы
Покажите на контекстной схеме покупателя, приложение оформления покупки, сервис заказов, платёжного провайдера и сервис выполнения заказов. Подписывайте назначение связей, а не просто рисуйте стрелки. «Авторизует платёж» объясняет больше, чем «API». Выделите сервис заказов как предмет обсуждения, а внешние системы разместите за его границей.
Рекомендации C4 по системному контексту предлагают сначала показать систему, её пользователей и подключённые системы в общем виде, а затем переходить к деталям. Чтобы разделять уровни рассмотрения таким образом, необязательно использовать все диаграммы C4.
Проследите один заказ от приёма до выполнения
Пронумеруйте взаимодействия, чтобы объяснить, что меняет новая очередь. Ниже — пример потока для вымышленной компании. Номера должны совпадать со схемой: тогда докладчик сможет указать нужный шаг, не разыскивая блок.
| Шаг | Взаимодействие | Что должна понять аудитория |
|---|---|---|
| 1 | Приложение оформления покупки отправляет запрос в сервис заказов | У запроса есть идентификатор заказа, по которому можно проследить весь путь |
| 2 | Сервис заказов подтверждает авторизацию платежа | При отклонённом платеже задание на выполнение заказа не создаётся |
| 3 | Сервис сохраняет принятый заказ и событие, ожидающее публикации | Проект должен учитывать сбой между сохранением заказа и публикацией события |
| 4 | Компонент публикации отправляет ожидающее событие в очередь | Публикация может повторяться; событию нужен стабильный идентификатор |
| 5 | Сервис выполнения заказов получает событие и сохраняет состояние обработки | Повторное событие не должно создавать вторую отправку товара |
| 6 | Эксплуатация видит состояние задания или уведомление о сбое | Очередь меняет не только путь запроса, но и работу по мониторингу и восстановлению |
Динамическая диаграмма C4 позволяет показать порядок взаимодействий при выполнении конкретного сценария. Используйте её выборочно: здесь важен путь сбоя и повторной обработки, а не каждый успешный вызов.
Не подписывайте этот пример «обработка строго один раз» или «заказы не теряются». Такие утверждения требуют деталей реализации и испытаний, которых презентация не содержит. Вместо этого обозначьте вопросы проектирования: как восстанавливаются ожидающие события, сколько хранятся задания со сбоем и кто отвечает за их повторную обработку.
Сравните варианты по одинаковым вопросам
Сравнительный слайд не должен ставить абзац преимуществ рядом с абзацем недостатков. Используйте одинаковые критерии и покажите цену каждого варианта.
| Критерий | Прямой вызов сервиса выполнения заказов | Выполнение заказов через очередь |
|---|---|---|
| Ответ покупателю | Приём заказа зависит от поведения вызова сервиса выполнения | Приём можно отделить от последующей обработки |
| Восстановление после сбоя | Повторные попытки остаются в цепочке вызова | Нужны состояния заданий, повторная обработка и защита от дубликатов |
| Работа эксплуатации | В этом потоке меньше отдельных элементов | Нужны ответственные за состояние очереди, задания со сбоем и отставание обработки |
| Переход | Новый путь сообщений не появляется | Нужны пилот и способ отката |
Таблица описывает вопросы проектирования, а не измеренную производительность. Добавляйте реальные данные о задержках или ошибках, только если можете указать среду, период, выборку и источник. Без этих данных обоснованная рекомендация — ограниченный пилот, а не якобы доказанное улучшение.
Соберите аргумент в шесть слайдов
- Решение и границы: предлагаемый пилот и то, что в него не входит.
- Контекст: сервис заказов и его непосредственное окружение.
- Текущая проблема: наблюдавшийся инцидент, задержка или эксплуатационное ограничение, из-за которого появилась идея изменения.
- Предлагаемый путь: шесть взаимодействий и точки сбоя.
- Варианты: четыре одинаковых критерия для обоих подходов.
- Решение о пилоте: ответственный, способ отката, испытания и дата оценки готовности продолжать.
В этом примере последний слайд может предложить команде платформы проверить сбой компонента публикации, повторную доставку события и недоступность сервиса выполнения заказов до оценки пилота. У каждой проверки должен быть ожидаемый результат и человек, который его интерпретирует. Так у встречи появляется конкретный итог, но презентация не выдаётся за окончательное решение архитектурного вопроса. После этих проверок презентация готовности к релизу свяжет результаты с конкретной версией-кандидатом, оставшимися блокирующими вопросами и человеком, уполномоченным разрешить или отложить запуск.
Создайте черновик из шести слайдов в Presenti, используя свой путь запроса, таблицу вариантов и условия пилота. Конфигурацию, журналы и полные результаты испытаний оставьте в приложении или связанном проектном документе: участники смогут изучить их, не перегружая основной рассказ.
