Про проверки идентификаторов и границы ответственности Иногда встречается подход: если в функцию по сигнатуре приходит id, то его нужно проверить на существование в БД. И так в каждой функции, через которую этот id проходит. Формально логика понятна: функция не знает, валиден ли вход. Но архитектурно это сигнал о другой проблеме - в системе отсутствуют доверенные границы. В любой системе есть: - точки входа, где данные считаются недоверенными и валидируются; - внутренний контур, где действуют инварианты и бизнес-логика работает, опираясь на контракты. Если каждый слой заново проверяет один и тот же id: - растёт количество одинаковых запросов; - сигнатуры функций перестают что-либо гарантировать; - бизнес-логика смешивается с инфраструктурными проверками; - система плохо масштабируется и по сложности, и по нагрузке. Архитектурная альтернатива: - валидировать идентификаторы и доступ один раз на границе сценария (controller / application service); - внутри бизнес-процесса считать: если мы здесь - сущность существует; - по возможности работать с объектами, а не с “сырыми” id; Повторные проверки внутри сценария - это не про надёжность, а про отсутствие договорённостей об ответственности слоёв. Реальная архитектура начинается не с диаграмм, а с ответа на вопрос: где в системе можно доверять данным, а где - нельзя.