【要約】ポートはドメインの必要から引く——LLMの実体を隠すPorts & Adapters [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がAIアプリのバックエンドに複数のLLMを採用しようとした際、実装の差異が密結合を招く問題に直面した。具体的には、以下の差異がドメインロジック（Scheduler）への侵入を招く懸念があった。
- ・通信プロトコルの違い（JSON-RPCによる子プロセス駆動とHTTP API）。
- ・状態管理の不一致（サーバ側で保持するステートフルと、毎回送るステートレス）。
- ・例外処理の乖離（タイムアウト等のエラー形式がバックエンドごとに異なる）。
// Approach
開発者は、ドメインの必要性のみに基づきPorts & Adaptersアーキテクチャを導入して境界を定義した。実装の詳細はアダプタ層に閉じ込め、ドメインには「細い面」のみを見せる手法をとった。
- ・ドメインが必要な最小限の操作（prompt, cancel, close）のみを定義したポートを作成。
- ・アダプタ内で、ステートレスなHTTP接続に対して会話履歴を保持する等の「状態の偽装」を実施。
- ・中立的な例外型を定義し、アダプタ側でインフラ固有の例外を継承させることで境界を正規化。
- ・MCP（Model Context Protocol）をアダプタの兄弟ではなく、アダプタに載る別レイヤとして整理。
// Result
設計の導入により、LLMの実体を隠蔽し、ドメインロジックを外部環境から完全に隔離することに成功した。
- ・LLMのバックエンドを差し替えても、ドメインであるSchedulerのコードを一行も変更せずに済んだ。
- ・ポートを利用したモック作成が容易になり、Schedulerのテスト容易性が向上した。
- ・設計の型をゲームエンジン等の別ドメインへ転用し、機能追加の速度を向上させた。
- ・将来的な高性能モデルへの移行に向けた、設計上の準備（繰り延べられた価値）を確保した。
Senior Engineer Insight
> 外部依存の揮発性が高いLLM領域において、この設計は極めて実戦的だ。単なるインターフェース分離に留まらず、状態管理の差異をアダプタで「飲み込む」判断が、ドメインの純度を保つ鍵となる。ただし、間接参照のコストと、AIが生成する「間違った抽象」のリスクには注意が必要だ。設計パターンを人間とAIの共通言語として活用しつつ、抽象化の責任を人間が握り続けることが、長期的な保守性を担保する唯一の道である。