visible true

技術的なメモを書く

Clean Architectureを理解するための補助的なコンポーネント図のようなもの

Clean Architectureを雰囲気でしか理解していなかったんだけど、なんでだろうな〜って考えるとあの図とか説明文がややこしいからだな〜と思った。 抽象的なやつはええねん、具体をくれ具体を〜、と思ったので、Android-CleanArchitectureのサンプルコードをコンポーネント図のようなものにおこした。

Android-CleanArchitecture Sample Code

実際にサンプルのソースを眺めると、レイヤの接続のための実装やAndroid固有(NavigatorなどIntentを処理するようなやつ)の実装などが混ざっていて、概念図とソースだけでは結構分かりづらい。しかもFragmentでActivityをキャストして使ってたり、UserCaseのコールバックをPresenterのインナークラスのObserverでやってたり、DataSourceは呼び出し毎に実装をnewしてたりわりとトリッキーだったり雑だったりするのでノイズが多い。

という事で概念が伝えている要素だけを抽出して関係だけを書いたコンポーネント図のようなもの*1を描いた。

f:id:sys1yagi:20170624213749p:plain

登場人物が少ないのでちょっとレイヤー化っていうイメージはつかみにくいなぁとは思うがこれはこれで理解の助けにはなるんじゃないかなと。

もうちょっと機能を足してみる

層感がないんでちょっと適当に機能を足してみた。新たな要素としてViewModelが加わっている。これは単純にViewのデータ群を管理するための要素として書いている。

f:id:sys1yagi:20170624213755p:plain

こういう図がいいのは実装を考えずにこうして機能を追加できたりする点だな〜とか思った。UML様〜。

それで

こういうのは各レイヤの責務が相互に漏れ出さないってのが重要なので、何かを足す時に気をつけないといけない。 たいていの場合Data層は固まるのが早い。初期のAPIセットを実装したら一旦終わるし、追加変更は大体同じようなことを繰り返すだけだからだ。 で、次にPresentation層。固まるっていうか表示要素とデータ、発生するイベントが決まれば大体OKだからどっちかっていうとレイアウトXMLの実装のほうが大変なくらいだ。 一番むずかしいのがDomain層で、ここが一番変化すると思う。特定のPresentation層に特化しすぎてたり、汎用的にしたけど結局共有できないから分離したり、試行錯誤が発生する。

まぁとりあえず概念の理解の助けになれば〜〜。個人的にはVIPERが好きだ。

*1:これって実際は何図って言うんだろう?