Шаблон RFC

Ниже приведен пример RFC, который можно использовать для твоей следующей разработки

Термины, специфичные для проекта.

Продуктовое описание проблемы и задачи проекта. Привести обоснование выбранных решений с точки зрения продукта.

Описание архитектуры на уровне C1–C2 нотации, с обоснованием выбранных подходов к реализации.

Редко вдаемся в подробности по типу:

• Какие таблицы будут у БД
• Как будем осуществлять fallback при такой-то интеграции
• Какой тип кеширование лучше заиспользовать

Но можно, если более сложная логика

Детали

Описание архитектуры более детально:

• Это может быть детальная проработка на уровне C2
• Также это может быть проработка на уровне C3, если хотим подсветить особенности работы какого-то компонента в сервисе
  • Например, у нас worker с большим количеством логики, походов в БД, смежных интеграций. Такой компонент лучше нарисовать и объяснить подробно
• Иногда бывают ситуации (скорее реже, чем чаще), что нужно спуститься на уровень C4
  • Например, мы делаем сложную интеграцию с банковским приложением и пониманием, что в ближайшем будущем точно будут схожие интеграции, но с другими банками. Мы, конечно же, хотим сделать интеграцию гибкой и переиспользовать раз к разу. Поэтому стоит подробно рассказать про классовые диаграммы, хитрые абстракции и тд

Здесь рассказываем про другие возможные подходы, если такие имеются

Проблема 1:

• Решение 1 — плюсы и минусы.
• Решение 2 — плюсы и минусы.
• Вывод 1 — выбранное решение и обоснование.

Проблема 2:

• Решение 1 — плюсы и минусы.
• Решение 2 — плюсы и минусы.
• Вывод 2.

После проработки и написания RFC необходимо Провалидировать архитектуру с кем-то более опытным и внести улучшения.

• Если изменения затрагивают смежные домены, то стоит попросить соседние команды также изучить твое RFC. Может быть ситуация, когда смежные команды смотрят RFC «по диагонали» и им все окей, но при Pull Requests выяснялось, что решение придётся переделывать