iOS

MVP(MVVM)とクリーンアーキテクチャに関する理解

More than 1 year has passed since last update.

概要

クリーンアーキテクチャのキモはUseCasesが依存関係の頂点にいることだと思うし原典でもそう書かれている。
Qiita他の記事でそこをないがしろにしていきなり登場人物を複数用意して実装の話をしていたり
そもそも実装サンプル読んだらそうなってない(依存方向が間違ってる)のもあったりして、もやもやした。

またクリーンアーキテクチャとMVPは両立できるのだが、まるで排他的な別物かのように書かれている記事があったりするのも気になった。

MVPとクリーンアーキテクチャ

Robert Martinによる原典を見ると、クリーンアーキテクチャで大事なのは依存ルールとある。

image.png

ユースケース・エンティティを内側に、壊れやすい外界を外側に置いて、内側にのみ依存させるのがキモであり、それ以外はどこにどういった実装を施すかは詳細には書かれてないし、状況によりけりでレイヤーも増えるともある。

MVPでいうMは、この図でいうUseCases、Entities、Gatewaysにあてはまると思う

また、図の右下が境界のまたぎ方。

右下の図は、どのように円の境界をまたがるのかの例だ。

とあるように、これも「例」でありパターンの一つでしかない。
依存関係を壊さなければどうやっても問題ないのであろう。

デリゲートパターンを採用しているMVPのPresenterは、このまんまの処理の流れを作っていると思う。
(図の例だとUsecaseだけど、MVPの場合、Viewの入力→Presenter(input用のInterface)→Modelで色々処理→Presenter→(output用のInterfaceから)Viewに出力、という流れ。)
クリーンアーキテクチャでこれをUseCasesとのやり取りでも行う

結論

つまりクリーンアーキテクチャは、

  • Mを分解した
  • 依存関係を整理し、最上位をUseCases+Entitiesにした。

というだけなので、MVPにクリーンアーキテクチャを適応することもできる

MVVMは、クリーンアーキテクチャの図でいう右下の境界のまたぎ方をデータバインディングにしただけなので、これももちろん両立できる。

参考