Этапы проектирования

Далее будут шаги, которые нужно выполнять друг за другом

Что стоит сделать:

• Провести грумминг проекта с заказчиком (менеджером, team lead или другими представителями вне команды).
• Определить один или несколько milestone — поэтапное донесение пользы пользователю.
• Обсудить сроки и последовательность раскатки.
• Понять, какая будет нагрузка.

К этому этапу можно возвращаться на любом другом этапе проектирования.

То, что оптимально и удобно технически, не всегда удобно для пользователя.

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

• Узнать, существуют ли решения, применимые в текущем проекте.
• Убедиться, что существующее решение действительно подходит под конкретные требования.

Нарисовать первое пришедшее на ум решение (соответствует принципу фиксации результатов).

Коротко о нотации C4: это метод визуализации архитектуры ПО, разработанный Саймоном Брауном. Он помогает представить систему на четырёх уровнях абстракции:

• C1 (Context): показывает, как система взаимодействует с внешними пользователями и другими системами.
• C2 (Containers): описывает высокоуровневую структуру системы (приложения, микросервисы, Messages Queues, базы данных и их взаимодействие).
• C3 (Components): детализирует внутреннюю структуру каждого контейнера, выделяя ключевые компоненты и их связи (APIs, workers, cron tasks и т. п.).
• C4 (Code): даёт детальный обзор реализации отдельных компонентов на уровне классов или функций.

RFC рекомендуется описывать на уровне C2–C3 нотации.

• Проанализировать возможные «костыли» в решении
• Проверить, является ли решение системным и масштабируемым
• Убедиться, что технологии и сервисы выбраны правильно
• Посмотреть, можно ли убрать некоторые компоненты или действия
• Оценить, выдержит ли предлагаемая архитектура требуемую нагрузку

А это будем подробно разбирать в следующей лекции.