【要約】[TypeScriptシリーズ - Part 8] Structural vs Nominal Typing [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
TypeScriptは構造が一致すれば異なる型でも互換性を認める「構造的部分型」を採用している。そのため、ドメインモデルにおいて意味的に異なる型（例：UserIDとOrderID）が、構造が同じであるという理由だけで混同され、論理的なバグを誘発するリスクがある。
// Approach
構造的部分型の柔軟性を維持しつつ、特定の型を区別するために「Branded Types」を用いる。これは、型定義に一意の識別子（ブランド）を交差型として付与することで、コンパイラに対して構造が同じであっても異なる型であることを認識させる手法である。
// Result
開発者は、柔軟性が求められる箇所では構造的部分型の恩恵を受け、厳格なドメイン境界が必要な箇所ではBranded Typesを適用するという、状況に応じた使い分けが可能になる。これにより、開発体験と型安全性の両立が図れる。
Senior Engineer Insight
> 構造的部分型は、モック作成や段階的な型定義において極めて高い生産性をもたらすが、大規模なドメインモデルを扱う際には「型による意味の保証」が欠落する危険がある。実戦では、すべての型を厳格にするのではなく、Value Objectなどの重要な境界にのみBranded Typesを導入する「選択的厳格化」が、運用コストと安全性のバランスを取る上で極めて重要である。安易な型定義は、将来的なリファクタリング時の破壊的変更を見逃す原因となるため、ドメインの重要度に応じた型設計の規律が求められる。