Практическое задание#

Контекст. Дана система электронной коммерции со следующими функциональными зонами

  • Заказы
  • Оплата
  • Каталог
  • Доставка
  • Уведомления

Текущая реализация:

  • Монолит
  • Одна база данных

Ограничения:

  • Команда: 8 backend-разработчиков
  • Релизы: 2 раза в неделю
  • Нагрузка: растёт, но не критично

Задание#

  1. Выбор архитектурного подхода, выбрать один вариант
    • Монолит
    • Модульный монолит
    • Микросервисы
    • Кратко объяснить, почему этот подход подходит под заданные ограничения
  2. Декомпозиция по домену
    • Выделить домены
    • Указать, какие домены могут эволюционировать независимо
  3. Владение данными
    • Определить источники истины для разных данных
    • Определить какие гарантии должны быть у разных доменов (eventual consistency)
    • Отметить потенциальные проблемные места (например, оплата ↔ заказы)
  4. Анализ рисков
    • Что будет сложно менять через год
    • Где возможен рост связности
    • Какие решения могут привести к distributed monolith

Обязательные артефакты#

  1. Архитектурные схемы
    • Контекстная
    • Компонентная
    • 1 Sequence диаграмма любого бизнесс-процесса в системе.
  2. ADR
    • Фиксирует выбор архитектурного подхода и содержит
      • Контекст
      • Решение
      • Альтернативы
      • Последствия
  3. Список трейдофов с примерами
    • Минимум 3 осознанных компромисса например:
      • Простота разработки ↔ масштабируемость
      • Консистентность ↔ автономность
      • Скорость релизов ↔ изоляция отказов

Правильное решение#

Единственного правильного решения не существует, поэтому возможны вариации, разбор от автора.

Контакты#

Поддержать автора