原始的執着 — 何でも string と int で表す

メールアドレスは string、金額は int、ユーザーIDも string。どれも基本型で表せてしまうので、つい生のまま持ち回します。しかしこの「なんでも基本型」が、検証の散乱と取り違えを静かに招きます。

横にスクロール

症状：どう気づくか

• 関数の引数が (string, string, string, int) のように、基本型ばかりが並ぶ。
• メール形式や金額が負でないかのチェックが、呼び出し側のあちこちに重複している。
• 「引数の順番を間違えて別のIDを渡していた」類のバグが起きる。

function transfer(fromId: string, toId: string, amount: number) { ... }

// 呼ぶ側：順番を間違えても型が同じなので誰も気づかない
transfer(toId, fromId, amount);   // from と to が逆！でもコンパイルは通る

なぜ悪いのか

第一に、検証が散らばる。「メールは形式が正しいか」「金額は負でないか」というルールは、その値の性質そのものなのに、基本型で持つと使う側それぞれがチェックすることになります。1箇所でもチェックを忘れれば、不正な値がすり抜けます。

第二に、取り違えを型が防げない。fromId も toId も同じ string なので、引数の順番を間違えても、user_id を期待する場所に order_id を渡しても、コンパイラは何も言いません。バグは実行時、しかも運が悪ければ本番で初めて表面化します。基本型は「文字列である」ことしか保証せず、「それが何の文字列か」という肝心な情報を持たないのです。

直し方

値オブジェクト（Value Object）を作る。 概念ごとに専用の型を用意し、生成時に検証し、その型でしか受け取らないようにします。

class Email {
  private constructor(readonly value: string) {}
  static of(raw: string): Email {
    if (!raw.includes("@")) throw new Error("不正なメール: " + raw);
    return new Email(raw);   // 生成できた時点で「正しいメール」が保証される
  }
}

class UserId { constructor(readonly value: string) {} }
class OrderId { constructor(readonly value: string) {} }

// UserId を期待する場所に OrderId は渡せない＝取り違えを型が弾く
function findUser(id: UserId) { ... }

一度 Email.of() を通れば、その値はもう検証済み。以降どこで受け取っても「正しいメールである」ことが型で保証され、各所での再チェックが要りません。UserId と OrderId は別の型なので、取り違えはコンパイル時に弾かれます。

まとめ

• 原始的執着は、意味を持つ概念を string / int のまま扱い続けること。メールも金額もIDもただの基本型になる。
• 害は、検証が使う側に散らばることと、同じ型どうしの取り違えをコンパイラが防げないこと。
• 直し方は値オブジェクト。専用の型を作り、生成時に検証し、その型でしか受け取らない。意味を型に乗せる。
• 一緒に現れる値の束（座標・金額と通貨）や、事故が起きた箇所から始めるのが現実的。