リクエストパイプライン

ミドルウェア登録順序

BFF のミドルウェアは以下の順序で登録する。外側（先に実行）から内側（後に実行）の順:

#	ミドルウェア	責務	参照
①	GlobalExceptionHandler	未処理例外の捕捉、RFC 7807 Problem Details 生成	→ エラーハンドリング
②	TraceIdResponseMiddleware	X-Trace-Id レスポンスヘッダーの付与	→ 分散トレーシング
③	CORS	許可オリジンのホワイトリスト検証	→ security-design.md
④	Session Authentication	Session Cookie の検証、サーバーサイドセッションから JWT 解決	→ 認証アーキテクチャ
⑤	RateLimiting	テナント別（1,000 req/min）、ユーザー別（200 req/min）	→ SR-008
⑥	PortalContext	URL プレフィックス（/employee/, /admin/ 等）からポータル種別を判定し IPortalContext に設定	—
⑦	TenantContext	JWT クレームから TenantId を抽出し ITenantContext に設定。RLS 用の SET app.current_tenant_id を発行	→ operational-architecture.md
⑧	Authorization	ロール・ポリシーベースの認可チェック	→ security-design.md
⑨	Endpoint	Minimal API エンドポイントの実行、MediatR Command/Query の送信	—

---

ポータル別ビューモデル変換

責務

Application 層の Query/Command 結果は、ドメインモデルに忠実な汎用的な形式で返却される。BFF はこれをポータルの対象ユーザーに最適化された ViewModel に変換する。

変換パターン: IPortalTransformer

// ポータル種別
public enum PortalType
{
    Employee,
    Admin,
    Agency,
    System
}

// ポータル別変換のインターフェース
public interface IPortalTransformer<TSource, TTarget>
{
    TTarget Transform(TSource source, PortalType portal);
}

具体的な変換例

CategoryJudgmentResult（→ DM-409）

12個の boolean フラグを持つカテゴリ判定結果を、ポータルに応じて開示レベルを制御する:

ポータル	変換内容
従業員	フラグ群を非表示。判定結果を自然言語サマリに変換（例:「配偶者控除の対象です」）。判定理由（JudgmentReasons）を平易な表現に変換
管理者	全フラグを表示。判定結果をテーブル形式で提供。手動オーバーライドが必要なケースのハイライト
代行事業者	全フラグ + 監査情報（判定に使用されたパラメータのバージョン、判定日時）。複数テナント横断の一括表示対応

CalculationDiff（→ DM-410）

3層の段階的開示データを、ポータルごとにデフォルトの開示レベルを設定する:

ポータル	デフォルト表示	展開可能
従業員	Layer 1（過不足額の変動）	Layer 2（控除の変動サマリ）
企業管理者	Layer 1 + Layer 2	Layer 3（カテゴリ判定変化）
代行事業者	Layer 1 + Layer 2 + Layer 3	全展開

BFF は CalculationDiffGenerator.Generate() の結果を受け取り、ポータルのデフォルトレベルに応じてレスポンスに含めるレイヤーを制御する。全レイヤーのデータは生成済みのため、フロントエンドがユーザー操作で追加レイヤーを要求した場合は、同じエンドポイントに ?detail=layer3 パラメータを付与して再取得する。

DeclarationSnapshot（→ DM-406）

ポータル別のフィールド可視性制御:

フィールド分類	従業員	管理者	代行事業者	sys_support
基本属性（氏名、住所）	表示	表示	表示	表示
申告内容（控除申請）	表示	表示	表示	表示
給与額・賞与額	非表示	表示	表示	マスク
マイナンバー（下4桁）	非表示	閲覧権限者のみ	閲覧権限者のみ	非表示
計算結果詳細	サマリのみ	全項目	全項目 + 監査	全項目（マスク）

→ 満たす要件: SR-004 認可要件、SR-009 データ分類