Самоорганизация команды вокруг требований, intentional архитектура - это правильно и модно. Я даже такое на тренингах советую. Но есть ряд вещей, которые должен решать только архитектор/техлид с группой избранных.
В основном, это касается явных (масштабируемость, скорость, нагрузка) и неявных (мониторинг, майнтейнабилити) нефункциональных требований. Для контроля исполнения обязателен архитектурный надзор, потому что разработчики на все ваши требования положат огромный болт. А разгребать это все придется вам.
Вот вам живой пример заваленного NFR
Observability. C ошибкой падает один из микросервисов, в логах одна строчка IllegalArgumentException: Invalid Data без указания чего бы то ни было. Ей богу, лучше бы стектрейс выплюнули. Воспроизводится, конечно же, только на окружении. А логи писать не нужно, потому что ну и так все работает и из кода понятно.Поэтому, если вы техлид или архитектор:
1. NFR всегда становятся частью Code Review. За несоблюдение - жесткая кара
2. То же логирование можно проверять на уровне анализаторов кода. Тогда карать будет бездушная железка.
Правила возводятся в абсолют, пока это не станет частью инженерной культуры.
А критерий проверки хороших логов - дать их почитать рандомному суппорту 2-3 уровня. Если он поймет где ошибка и что с ней делать, то логи годные.