Речь о snake_case и camelCase 🤨

На разных проектах не раз видел одну и ту же картину. Пока система маленькая - всем ок, «как-нибудь договоримся». Потом проект растёт, подключаются новые команды, и начинается классика: user_id здесь, userId там, userID в третьем месте.

Товарищи по профессии часто жалуются на одно и то же: баг вроде бы «на 5 минут», а полдня уходит только на выяснение, в каком слое поле уже переименовали, а в каком ещё нет.

И вот в этот момент хорошо видно: спор про snake_case и camelCase вообще не про стиль. Он про надёжность договорённостей между слоями.

❗️ Внешний контракт должен говорить на одном языке (часто это snake_case) - без «для этого клиента сделаем по-другому». ❗️ Внутри фронта пусть остаётся привычный camelCase, но преобразование должно жить в одном adapter-слое. ❗️ Если маппинг раскидан по компонентам и сервисам, неточности копятся тихо и выстреливают в релизах. ❗️ BFF (Backend For Frontend) помогает держать эту границу чистой, когда реально появляются разные клиенты и сложные агрегации.

Я для себя это формулирую просто: единый контракт наружу, удобные модели внутри, и никакой «магии» с полями между ними.

Тогда исчезает большая часть мелкого интеграционного шума, который обычно съедает внимание команды сильнее любых «больших» задач.

У вас это уже зафиксировано как правило или пока каждый новый endpoint живёт по своим именованиям?