Android開発でCleanArchitectureやら諸々の技術をひっくるめて使った結果、色々見えてきたのでそのメモ。
ほとんど自分向けなので大雑把な内容しか書いてないです。
清書する日が来るかどうかは未定
主に使用した技術の話
使ってみたかったやつ
- RetroLambda
プロジェクト構成の話
AndroidのCleanArchitectureで検索すると、だいたいはここに行き着くと思う。
が、この構成はプロダクトが大きければ大きいほど不向きであることが見えてきた。
理由は、機能(画面)ごとの見通しが悪くなるから。
アプリとして１、２画面しか持たないのであればさほど問題にならないが、10画面以上も持つアプリで、さらに個々の画面で異なる機能を提供する場合、途端に見通しが悪くなった。これはUseCaseとPresentationの結びつきが強いことに起因している。
なので、方針として、データ層のみは固めて、プレゼンテーション層とドメイン層は機能毎にパッケージを切ることで、比較的すっきりした構成にすることができた。
データ層のみを固めた理由は、画面への依存が薄く、かつ複数のUseCaseから呼び出される可能性が高いから。
root
L data
L datasource
L entity
L funcA
L funcB
・・・
L funcN
L usecase
L presentation
CleanArchitectureの向き不向きの話
まずはCleanArchitectureのメリット・デメリットを簡単に整理。
メリット
- 可読性が高くなる
- 拡張性が高くなる
デメリット
- ソースコードが多くなる
- クラス分けが細かくなる
上記のメリット・デメリットを踏まえた上で向いている開発、向いていない開発をまとめてみた。
向いている開発
- 大規模な開発
- 複数の会社にまたがった開発（受託発注など）
- 長期の運用、メンテナンス、エンハンスが予測される開発
- 既に存在しているプロジェクトを大規模リファクタリング（作り直し）するような開発
向いていない開発
- 小規模な開発
- 単独で行うようなの開発
- 長期の運用や、メンテナンス、エンハンスがないような開発
向き不向きの判断は個人的主観によるもので、実際に体験してるものもあれば、想像で書いているものもあるが、おおよそ合ってるのではないかなぁと。
結局はメリットとデメリットに対してどのような開発がメリットを最大化できるか、という話なので、大規模で、いろんな人が関わっていて、今後もメンテナンスが必要な開発、に向いているというだけの話。
サーバ間のAPIの話
Swagger,Retrofit2,Dagger2,RxJavaを使っているとサーバ間通信の実装が数行で終わる。
※ただしDagger2関連の記載部分は除く（と言ってもDagger2の記載を含めても50行ない)
@Singleton
public class SomeRepository implements ServerSomeApi {
private final ServerSomeApi mServerSomeApi;
@Inject
public SomeRepository(ServerSomeApi serverSomeApi) { mServerSomeApi = serverSomeApi; }
@override
public Observable<SomeEntity> getSomeEntity(String param1) {
return getSomeEntity(param1);
}
}
これでgetSomeEntityメソッドを叩くと、サーバからSomeEntityを取得できる。もし新たなAPIが追加されてもメソッドを追加して中身を1行実装するだけで終わる。
UseCaseをどう作るかという話
おおざっぱにはCleanArchitectureの考え方に沿って、プレゼンテーション層で使うデータを作る方針で問題なかった。
データ層が木の板だとするなら、UseCase層ではその板をくっつけたりして犬小屋を作ったり、椅子を作ったりするイメージ。