TypeScriptの「境界」を設計せよ：Branded Typesによるドメイン駆動の型安全革命
TypeScriptは強力だが、その型システムは「構造的部分型（Structural Subtyping）」という甘美な罠を孕んでいる。`string`はどこまで行っても`string`であり、ドメインモデルとしての意味論をコンパイラは追跡しない。
多くのエンジニアが「型安全だ」と信じているコードは、実はランタイムにおけるデータ混入に対して無防備なハリボテに過ぎない。本稿では、TypeScriptのコンパイル時メタデータと交差型（Intersection Types）を悪用し、ドメインの境界を鉄壁にする「Branded Types」の極致を解説する。
—
1. 構造的部分型の「欺瞞」とコンパイラの限界
TypeScriptにおいて、以下のコードはエラーにならない。
type UserId = string;
type OrderId = string;
function processOrder(id: OrderId) { / … / }
const userId: UserId = “user_123”;
processOrder(userId); // コンパイラは黙認する。なぜなら両者ともstringだからだ。
これはTypeScriptの設計哲学である「JavaScriptの柔軟性の継承」の結果だが、DDD（ドメイン駆動設計）の観点からは致命的な脆弱性だ。コンパイラは「型名」ではなく「構造」を見ている。この防壁を突破するには、型システムに「存在しないはずのタグ」を焼き付ける必要がある。
—
2. Branded Types：型システムへの「烙印」
Branded Typesの正体は、交差型を用いた「識別子の強制」である。
// 幽霊のようなタグを定義する
interface Brand
readonly _brand: B; // 実行時には存在しないメタデータ
readonly _value: T;
}
type Branded
// ドメインプリミティブの定義
type UserId = Branded
type OrderId = Branded
const createUserId = (id: string): UserId => id as UserId;
ここで重要なのは、`_brand` プロパティが物理的にメモリに確保されることはないという点だ。コンパイル時、TypeScriptの型チェッカーは「このオブジェクトは `string` であり、かつ `_brand` というタグを持っているか？」を確認する。
—
3. コンパイラの内部挙動と最適化
シニアエンジニアとして知っておくべきは、このテクニックが「ゼロ・ランタイム・オーバーヘッド」であるということだ。
TypeScriptコンパイラ（`tsc`）によるトランスパイル過程で、`_brand` プロパティは完全に消去される。JavaScriptランタイムにおいては、単なる `string` として処理されるため、メモリリークやガベージコレクションの負荷増大は皆無だ。
しかし、防御力は劇的に向上する。
function processOrder(id: OrderId) {
console.log(`Processing order: ${id}`);
}
const myUserId = createUserId(“user_123”);
// processOrder(myUserId); // ！！コンパイルエラー！！
// 型エラー: Type ‘UserId’ is not assignable to type ‘OrderId’.
このエラーこそが、ドメイン駆動設計における「最強の防壁」である。型が衝突する境界で、コンパイラという検問所が自動的に機能する。
—
4. 厳密な防壁を突破されるケース：型の「緩さ」への対抗策
Branded Typesを使っていても、以下のコードは危険だ。
// 型アサーションによる突破
const fakeId = “admin_hack” as OrderId;
`as` による強制キャストは、TypeScriptの型システムを無効化する最も直接的な攻撃ベクトルである。この突破を防ぐには、「スマートコンストラクタ」の実装が不可欠となる。
/
- スマートコンストラクタ
- 外部境界（APIリクエスト等）からの入力を、ここで検証して型付けする。
/
function toOrderId(value: string): OrderId {
if (!value.startsWith(“ORD-“)) {
throw new Error(“Invalid OrderId format”);
}
return value as OrderId;
}
境界の外側（JSONのパース結果など）からデータを取得する際、必ずこのコンストラクタを通すこと。ここが防衛のフロントラインとなる。
—
5. アーキテクトとしての提言：なぜ今Branded Typesか
大規模なNode.jsアプリケーションでは、型定義の乖離が最大の負債となる。特にイベントループを回る非同期処理において、`any` や単なる `string` が伝播すると、バグの追跡は困難を極める。
Branded Typesを導入することは、「型によるドキュメント化」を自動化することと同義だ。関数のシグネチャを見ただけで、その値が「生データ」なのか「ドメインで検証済みの値」なのかが一目瞭然になる。
まとめ：TypeScript掌握のためのチェックリスト
1. プリミティブを避ける: ドメイン層で `string`, `number`, `boolean` をそのまま使わない。
2. 不変性を担保する: `readonly` を併用し、識別子の変更を許さない。
3. 境界で検証する: スマートコンストラクタを実装し、型アサーションを局所化する。
4. ランタイムを信じない: 実行時は常に `unknown` からの検証プロセスを徹底する。
TypeScriptの型システムは、単なるバリデーターではない。それは、あなたが設計したドメインモデルという名の「城」を守るための、不可視の防壁なのだ。この防壁を使いこなせ。言語そのものの仕様を掌握した者にしか、真の堅牢性は構築できない。