目次を開く
結論
置き換えられない外部APIの依存をアダプターへ閉じ込め、アプリケーションが使う契約を独立させる。
背景
Windows上のCOMや独自形式を前提とする外部サービスを、ブラウザから利用したい場合がある。変更できるアプリケーションと変更できない外部システムの境界から考える。
設計と検証の論点
構成を検討するときは、次の責任と境界を分けて確認します。
- COMインターフェース
- F#アダプター
- 腐敗防止層
- ドメインモデル
- REST API
- Reactアプリケーション
判断理由
外部サービスを変更できない制約の下では、全面書き直しを選択肢に置くだけでは解決しない。COMの型や状態をF#アダプターで扱い、ドメインモデルとREST契約を介してReactへ渡す。既存サービスの機能を維持する判断と、アプリケーション側の変更を独立させる判断を分けて説明する。
トレードオフ
アダプターは変更の影響を閉じ込めるが、WindowsやCOMへの依存そのものを消さない。データ変換、エラーの対応、APIの版管理が新たに必要になる。REST化に伴う遅延や部分失敗も設計対象に含める。
制約
変換前後の型、エラー対応表、契約のテスト例を確認する。技術顧問の先行アダプター資産とCoRISEの顧客向け実装の担当範囲を分ける。
関連事例
関連事例の担当範囲や設計判断を参照します。記事で提案する実験・構成を、その事例で実施済みとするものではありません。