Clean Architecture では AP のデプロイをどう扱うべき？

インフラ的なコードを Clean Architecture を使って設計するとき、デプロイはどう扱ったらいいんだろうか？

エンティティの永続化

デプロイについて考える前に、より馴染みのある「エンティティの永続化」について考える。

例えば、User というエンティティを MySQL を使って永続化する場合、どのような設計にするだろうか？

よくあるパターンでは、

1. ドメイン層に UserRepository というインターフェイスを作る。
2. UserRepository を使って User の永続化に関するビジネスルールを記述する。
3. アダプタ層で UserRepository を実装したクラス MySqlUserRepository を作る。

みたいな感じになる。

エンティティのデプロイだとどうなる？

デプロイでも永続化と同じような設計ができるのでは？と最近考えてる。

ApServer というエンティティを Kubernetes 上にデプロイする状況があるとする。 このとき、以下のような設計にすると見通しがよいのではないだろうか：

1. ドメイン層に ApServerDeployer というインターフェイスを作る。
2. ApServerDeployer を使って ApServer のデプロイに関するビジネスルールを記述する。
3. アダプタ層で ApServerDeployer を実装したクラス KubernetesApServerDeployer を作る。

永続化の例との対応は以下のようになる。

	永続化	デプロイ
エンティティ	User	ApServer
インターフェイス	UserRepository	ApServerDeployer
外部サービス	MySQL	Kubernetes
プロトコル	SQL	Manifest

まだアイデアレベルで、この設計を実際に試したわけじゃないので、機会を見つけて試してみたい。