Практика рассчитана на отдельную учебную среду и вымышленные данные.
Ландшафт систем
Контекстная карта отвечает, кто пользуется системой и с кем она взаимодействует. Это обзор ответственности и зависимостей, а не список технологий.
Карта системы показывает участников, внешние границы и ответственность. Начните с одного сценария: пользователь оформляет заказ, сервис сохраняет его, интеграция передаёт уведомление. Подпишите владельца каждого состояния и направление обмена. Не смешивайте на первом рисунке все серверы, функции и продуктовые решения: это затрудняет ответ на главный вопрос.
- Граница системы
- Пользователи
- Внешние зависимости
Попробуйте
- Нарисуйте сервис записи на занятия, ученика, администратора и внешнюю почту.
- Укажите назначение каждой связи и владельца записи.
- Сравните свою карту с Context в интерактивном примере C4.
Внешняя почта вне границы сервиса; участники и направления обмена понятны.
Почему база данных не всегда появляется на Context diagram?
На этом уровне показывают систему целиком; её внутреннее хранилище раскрывается на уровне Container.
Продолжить на русском и английском
- C4 model EN ↗
Context и Container diagrams. Открытый авторский материал; рисовать можно на бумаге.
- C4 interactive example EN ↗
Перейдите от контекста к контейнерам. Просмотр диаграммы в браузере; это пример, не проверка кода.
- Azure Well-Architected Framework RU ↗
Надёжность, безопасность и эксплуатационные компромиссы. Обзор принципов; облачная практика и аккаунт для чтения не требуются.
Интеграции
Синхронный вызов связывает время ответа участников; сообщение позволяет разделить их по времени. Выбор зависит от требуемого результата и поведения при отказе.
Синхронный вызов даёт ответ в рамках запроса, а сообщение отделяет отправку от дальнейшей обработки. У каждого подхода своя цена: ожидание и зависимость от доступности либо задержка и необходимость управлять повторной доставкой. Сначала определите, нужен ли пользователю окончательный результат немедленно, затем выбирайте механизм.
- Request/reply
- Очередь сообщений
- Дубликаты и порядок
Попробуйте
- Для записи на занятие отделите сохранение места и отправку уведомления.
- Сравните вариант «ждать почту» с вариантом «зафиксировать запись и отправить позже».
- Опишите повторную доставку одного уведомления и способ распознать дубликат.
Понятно, когда пользователь получает успех и что происходит при недоступной почте.
Устраняет ли очередь необходимость обработки ошибок?
Нет. Нужны повторы, наблюдение, ограничение попыток и стратегия сообщений, которые постоянно не удаются.
Продолжить на русском и английском
- Enterprise Integration Patterns EN ↗
Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.
- C4 model EN ↗
Context и Container diagrams. Открытый авторский материал; рисовать можно на бумаге.
- Azure Well-Architected Framework RU ↗
Надёжность, безопасность и эксплуатационные компромиссы. Обзор принципов; облачная практика и аккаунт для чтения не требуются.
Контракты и границы
Компонент обещает соседям определённое поведение, а внутреннюю реализацию может менять. Контракт должен задавать смысл полей, ошибки и ответственность за данные.
На границе определяют формат, семантику, полномочия и способ ошибки. Два сервиса могут успешно разобрать один JSON и по-разному понять его статус. Поэтому пример payload дополняют правилами переходов и совместимости. Изменение смысла старого поля опаснее добавления нового необязательного поля с явной договорённостью.
- Вход и выход
- Владелец данных
- Совместимость
Попробуйте
- Опишите контракт createBooking: courseId, learnerId, requestId → bookingId или ошибка.
- Укажите, кто решает, есть ли свободное место.
- Сравните добавление необязательного поля и смену значения существующего поля.
Владелец проверки вместимости назван; совместимые и несовместимые изменения различены.
Почему общая таблица не всегда хороший контракт?
Она раскрывает внутреннюю схему и связывает изменения потребителей; ответственность и совместимость становятся неявными.
Продолжить на русском и английском
- C4 model EN ↗
Context и Container diagrams. Открытый авторский материал; рисовать можно на бумаге.
- Enterprise Integration Patterns EN ↗
Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.
- Обзор HTTP RU ↗
Запрос, ответ, метод, статус и заголовки. Чтение открыто; собственные запросы выполняйте к учебному сервису.
Потоки данных
Проследите одну запись от ввода до использования и отметьте все преобразования. Так видны источник истины, задержки и места возможного расхождения.
Проследите один факт от появления до использования: кто его создал, где хранится исходник и какие копии появляются дальше. Подпишите задержку и условия обновления каждой копии. Если отчёт отстаёт от формы ввода, это может быть ожидаемым поведением потока, а не потерей записи. Проверять нужно обещанную границу задержки.
- Источник истины
- Преобразование
- Хранение и потребители
Попробуйте
- Проследите bookingId от формы через API в БД и письмо.
- Для каждого перехода укажите идентификатор, проверку и момент фиксации.
- Разберите, что увидит отчёт, если письмо задержалось на час.
Запись в БД не смешивается с отправкой письма; отчёт читает согласованный источник.
Чем команда отличается от события?
Команда просит действие, событие сообщает уже состоявшийся факт; это влияет на название, владельца и обработку повторов.
Продолжить на русском и английском
- Enterprise Integration Patterns EN ↗
Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.
- C4 model EN ↗
Context и Container diagrams. Открытый авторский материал; рисовать можно на бумаге.
- Azure Well-Architected Framework RU ↗
Надёжность, безопасность и эксплуатационные компромиссы. Обзор принципов; облачная практика и аккаунт для чтения не требуются.
Надёжность связей
Большая система может частично отказать, оставаясь полезной пользователю. Явно определяйте критичный путь, деградацию и восстановление обмена.
Интеграция считается успешной по бизнес-результату, а не только по HTTP 200 посредника. Определите подтверждение обработки, ключ повторной операции и место сверки. При временном отказе важны ограниченное ожидание, понятный повтор и видимое состояние для оператора. Установите ответственность за незавершённые операции заранее.
- Частичный отказ
- Retry/DLQ
- Сверка состояния
Попробуйте
- Сервис записи работает, почта недоступна 30 минут: задайте ожидаемое поведение.
- Опишите очередь, предел повторов и сигнал о накоплении сообщений.
- Добавьте сверку: какие подтверждённые записи ещё не получили уведомление.
Пользователь не теряет сохранённую запись; повторное сообщение не создаёт новую запись.
Гарантирует ли повторную доставку отсутствие дублей?
Наоборот, повтор может дать дубликат; обработчик должен уметь распознавать повтор одной операции.
Продолжить на русском и английском
- Enterprise Integration Patterns EN ↗
Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.
- Site Reliability Engineering books EN ↗
SLO, мониторинг и разбор инцидентов. Открытые онлайн-книги; материал для этапа после основ.
- Azure Well-Architected Framework RU ↗
Надёжность, безопасность и эксплуатационные компромиссы. Обзор принципов; облачная практика и аккаунт для чтения не требуются.
Проектирование системы
Сначала выясните пользовательский сценарий и ограничения, затем выбирайте компоненты. Хорошее решение можно объяснить вместе с его ценой и условиями пересмотра.
Проектирование начинается с ограничений: нужные сценарии, объём, допустимая задержка, чувствительность данных и команда поддержки. Рассмотрите простой вариант и одну обоснованную альтернативу. Для каждого добавленного компонента объясните выигрыш и новый способ отказа. Схема становится полезной, когда помогает выбрать и проверить компромисс.
- Требования и ограничения
- Context/Container
- ADR и компромиссы
Попробуйте
- Спроектируйте запись на 20 занятий для 200 учебных пользователей.
- Нарисуйте веб-клиент, API и БД и опишите ограничение на число мест.
- Напишите два коротких ADR: почему одна БД и почему уведомления отправляются отдельно.
Каждое решение связано с требованием; названы условия, при которых архитектуру стоит пересмотреть.
Нужны ли микросервисы для первой версии?
Не сами по себе. Дополнительные границы оправданы независимым масштабированием, ответственностью или другим явным ограничением.
Продолжить на русском и английском
- C4 model EN ↗
Context и Container diagrams. Открытый авторский материал; рисовать можно на бумаге.
- C4 interactive example EN ↗
Перейдите от контекста к контейнерам. Просмотр диаграммы в браузере; это пример, не проверка кода.
- Azure Well-Architected Framework RU ↗
Надёжность, безопасность и эксплуатационные компромиссы. Обзор принципов; облачная практика и аккаунт для чтения не требуются.
- Enterprise Integration Patterns EN ↗
Message Channel, Message Router и повторная доставка. Авторский каталог паттернов; чтение, не браузерный тренажёр.
Запись есть, письмо не пришло
Проведите границу успеха и разберите отказ внешней зависимости. Это вымышленный учебный сценарий.
1. Определите успех
Пользователь бронирует место.
Требование: недоступность почты не должна отменять сохранённую запись.Что считать обязательным до ответа об успехе?
2. Учтите повтор
Сообщение о booking-17 доставлено обработчику второй раз.Как предотвратить повторное бизнес-действие?
3. Не потеряйте уведомление
Запись в БД выполнена; процесс упал до публикации сообщения в очередь.Что стоит проработать в дизайне?