RFC — request for changes. Данный подход используется для описания нового функционала (от заведения сервиса до фичи в рамках существующих сервисов), для изменения процесса разработки и тд.
Ниже будут описываться принципы и этапы проектирования архитектуры в рамках RFC, включая использование C4-нотации для визуализации и документации системы.
Зачем вообще нужен данный процесс
- Пускать в разработку только качественные и проверенные решения
- Заставляет разработчика на этапе проработки думать о всех нюансах будущего решения
- Позволяет делиться знаниями и опытом между командами при cross-review. Это также позволяет уменьшать одни и те же ошибки
В каких случаях обычно пишут RFC
- Создается новый сервис
- Создается новая БД
- Значительно дорабатывается существующий сервис
- Сильно меняется существующая логика
- Доработка вносится на несколько сервисов и хочется получить ОК от другой команды
Принципы описания
- Описываем от общего к частному (это помогает сохранить логичность и последовательность)
- например: Domain → Service → API → Function
- Описание должно формировать одинаковое представление у разных людей (это снижает риск недопонимания и уменьшает вероятность переделок в будущем).
- В начале RFC задать термины, которые используются в текущей доменной модели
- Фиксируй все, даже если это кажется излишним. Иногда один упущенный элемент может привести к глобальным переделкам
Ответственность за RFC распределяется между разными людьми
- Автор ревью (функционала) — отвечает за оформление по канону (если такое есть в компании) и качественную проработку
- Ревьюер от смежной команды — за ревью сервисов в зоне ответственности этой команды
- Ревьюер от команды архитектуры — за ревью между разными доменами, чтобы обеспечить высокое качество архитектуры в отделе/подразделении