設計原則

1. 設計原則

idp-server の中心的な設計理念は、OIDC の世界観を尊重することです。

1.1 プロトコルの妥当性

• 相互運用性と明確性を確保するため、OAuth 2.0 および OIDC 仕様に厳密に準拠する
• 標準からの逸脱は厳格に禁止（拡張機能はカプセル化する必要がある）

1.2 拡張性と互換性のバランス

• CIBA、FAPI、OID4IDA などの拡張仕様の柔軟な実装をサポート
• 拡張機能は標準フローにシームレスに統合する必要がある

1.3 抽象化による実装の自由度

• OIDCの仕様でカバーされていない部分（認証、永続化、通知など）は、プラグイン可能な設計にすること

---

2. 設計ガイドライン（再設計）

2.1 層と責務の分離（Hexagonal Architecture）

• Controller層（SpringBoot Adapter）

  • 入出力のDTO変換のみ
  • ロジック・リポジトリアクセスは禁止

• UseCase層（UseCases）

  • ユースケースごとに1クラス（EntryService）
  • トランザクション制御、プロトコル切り替え、永続化を担当

• Core層

  • OIDC仕様に沿ったドメインモデルとプロトコル検証
  • 型安全な値オブジェクト（例: GrantId, ClientId, AcrValue）
  • OIDC仕様に沿ったRestAPI用のレスポンス生成

• Adapter層（DB）

  • CommandRepository, QueryRepository に責務を分離
  • 永続化処理をカプセル化

2.2 型と命名規則

• OIDCの用語やユースケースに対応した明確な命名
• 意味のある型を優先し、StringやMapの利用は最小限に

2.3 制御フローの設計指針

• アプリの振る舞いを変える分岐処理は、Strategyパターンを利用する。
  • 例: トークンリクエストのgrant_typeによる分岐処理。

2.4 拡張性

• 各種 PluginLoader を活用し、差し替え可能なアーキテクチャに

2.5 テスト方針

テストタイプ	対象	内容
ユニットテスト	Domain, Protocol	単体ロジックの確認
ユースケーステスト	EntryService	フロー単位のモック付きテスト
E2Eテスト	REST API	リクエスト〜レスポンスの統合確認
認定テスト	OIDC/FAPI	プロトコル準拠を自動検証（conformance）

2.6 アンチパターン集

• 共通ロジックをとりあえず Util クラスにしないこと
• Map<String, Object> に逃げないこと
  • 責務が不明瞭になるので、専用クラスかドメインモデルで表現する
• DTO にドメインロジックを含めないこと
  • DTOはただのデータ転送。ロジックはドメインモデルに寄せる
• キャストは基本的に使わないこと
  • キャストが不要になるよう設計を見直す
• 永続化層内でドメインロジックを実行しないこと。
  • 永続化の責務に徹し、ロジックは Core に寄せる