三つ巴の命名規則 ― 混沌の館へようこそ

SPA を作ることになって分かったけど、

命名規則って 2つまでならまだ大丈夫なんだよね。
3つ以上になると一気に崩れる。

新しい Web システムを SPA で作ることになったので、
念のためフロント・API・DB の命名を全部調べてみた。

そしたらまあ、静かに驚いた。

---

■ 2つの組み合わせだけなら、まだ耐えられる

フロント + API

→ JSON を camelCase にしておけば、そこそこ自然にそろう。

HTML + DB

→ フレームワーク次第だけど、“翻訳ポイントはひとつ” だからまだ扱える。

どちらも、
「ズレはあるけど破綻はしない」
というレベルで済んでいた。

---

■ ところが、3つ以上の組み合わせになった瞬間、途端に破綻する

フロント + API + DB。
この3つを同時に扱い始めたときだけ、急に様子が変わる。

• snake_case（DB）
• PascalCase（C# / DTO）
• camelCase（API / JSON / TS）

これらが同時に動き出すと、
翻訳ポイントが複数発生して、誰も全体を把握できなくなる。

実際に調べてみると、
名前がそろっているレイヤのほうが珍しいくらいだった。

地味なんだけど、こういうのが積み重なる。

• JOIN でフィールド名が衝突する
• JSON と DTO の微妙な揺れが数ヶ月後に発火する
• user_id / UserId / userId が 3 種類そろう
• どれが「正しい名前」か人によって意見が違う
• カラム追加で API が黙って壊れる

別に誰が悪いという話ではない。
ただ、構造的にそうなりやすいだけ。

---

■ みんな困ってないのかな？

昔ながらの Web アプリなら、
HTML と DB の間だけで完結していたから、
ここまで深刻ではなかったと思う。

SPA になって、

フロント→API→DB
という “3段構え” が当たり前になった瞬間に、
命名のズレが一気に表面化したんだろう。

でも不思議と、
「あれ？これまずくない？」という声を
あまり聞かない。

みんな平然と進めているけど、
実際のところ困ってないのだろうか。

---

■ 調査結果はあとでまとめるけど

正直に言えば、
ひとつひとつ見ていると なかなか面倒な話 だった。

このあたりは、
自分でも、もう少し整理しておきたいところ。

きっちりまとめておかないと、寝つきが悪い。

---