コンテキストマップ — 設計への含意

領域の分解と対応関係の定義に基づき、設計レベルでの指針を示す。

→ 領域の定義と用語の対応は コンテキストマップ 参照

モジュール境界とAPI設計

領域間の対応関係の本数が、モジュール間の結合度を可視化する。対応関係が存在する箇所には、Anti-Corruption Layer やドメインイベントによる連携が必要になる。

• 領域内リレーション（概念ER図の実線）: 同一モジュール内のエンティティ間関係。直接的な参照（FK等）で実装する
• 領域間の対応（概念ER図の赤破線）: モジュール間の接続点。共有IDによる論理的な参照、またはドメインイベントで実装する

データベース設計

領域内のリレーションはテーブル間の FK に対応し、領域間の対応は共有IDによる論理的な参照になる。同じ実体でも領域ごとに別テーブルにすることで、各領域のスキーマ変更が他に影響しない独立性を得る。

例: 給与領域の「給与の支払者」テーブルのスキーマ変更は、組織領域の「企業」テーブルに影響しない。

Fact → Judgment → View との対応

領域の分解は、Fact → Judgment → View の3層モデルと対応する:

• 家族: 年度属性 = Fact の管理（所得見積額、障害区分、住所等）
• 申告: 申告・控除 = Fact の収集と Judgment への入力
• 給与: 税額計算結果・源泉徴収額 = Judgment（控除適用後の年税額）

アイデンティティは3層モデルの外側に位置する横断的関心事であり、すべての層の領域にユーザー認証を提供する。

各領域が3層モデルのどの層を主に担当するかが明確になり、責務の分離が自然に実現される。