アプリケーションと外部システムとの境界で、API Client や Wrapper と呼ばれるものが使われることが多い。 ただし、API Client や Wrapper は汎用的な処理を配置するにあたって便利な一方で、アプリケーションのドメインロジックが詰め込まれてしまうこともある。 ドメインロジックと外部システムの境界という観点から、よく使用される API Client や Wrapper の責務を明確にして、設計時の指針にしたい。
API Client と Wrapper がどのような目的で使用されるかについて、以下の設計パターンを参考に整理していくことにする。
DDD 文脈では、外部システムとの境界に配置し、ドメインモデルが外部システムの仕様に直接依存しないようにする。 API Client、Wrapper、Transformer などの要素から構成される。
PoEAA では、ドメインモデル層との境界で Gateway パターンや DTO パターンの活用が推奨されている。
いずれも、ドメインモデルを扱う層と外部システムとの境界を明確に分けて直接的な依存を避けるような設計を行っている。(PoEAA との対応のさせ方は少し自信がないので、腐敗防止層で理解した方がよさそう。巷のパターンがドメインモデルとの境界を分けることを意識していることが伝われば) また、外部システムを扱う機能としても、大きく分けて以下の 3 つの要素で構成されていることが分かる。
今回は、この層を構成する要素を API Client と Wrapper として話しを進めていくことにする。 (自分がこれまで見てきた事例として、Transformer は API Client や Wrapper に内包されていることが多かったため)
API Client と Wrapper を以下のように定義する。
腐敗防止層的な層の設計や実装方法は分け方も様々なので、層の中で徐々に責務分割していく。
この層には持たせない。 Wrapper や API クライアントにドメインロジックを書き始めたら、ドメインを扱う層で扱うことを検討する。
例: API の提供元から、API Client と SDK が提供されており、一部の機能が API Client からしか使えない場合。
どちらでも操作可能な場合に、実装者によって使用するコードがブレる可能性があるため、ルールが必要になる。まず、API Client と SDK を併用することの是非を問う。
それでも必要な場合は