Архитектура раньше накопления
У сложности должна быть причина. Система не становится лучше только потому, что в ней больше сервисов. Первый вопрос — оправдана ли новая служба, абстракция или зависимость реальной эксплуатационной нуждой, а не тем, что её можно добавить.
Видимость в эксплуатации
Развёрнутое приложение должно давать достаточно, чтобы понять, что оно делает и почему что-то сломалось. Логи, метрики, трейсы и health-эндпоинты — часть системы, а не украшение перед дедлайном.
Явные границы
Права, сервисы, владение данными и ответственность должны быть понятны, а не подразумеваться. Неявные границы становятся инцидентами. Если ответственность размыта, система рано или поздно ведёт себя так, будто ею никто не владеет.
Обратимые решения
Инфраструктура и софт не должны запирать без нужды. Если выбор трудно откатить, эта цена должна быть видна и намеренна.
Доказательства важнее оформления
Успешный HTTP-ответ ещё не доказательство, что бизнес-процесс дал верный результат. Система правильна, когда правилен эксплуатационный исход.
Продакшен — часть разработки
Деплой, мониторинг, бэкапы, миграции и восстановление после сбоев — часть инженерии, а не работа, которая начинается после разработки.