Clean ArchitectureでAndroidアプリのクラス設計をしてみる
結論
こんな感じになった。
こんなシステムを想定した
- Webサイトで公開されている小説情報を表示したい
- Webサイトの検索機能を使えば、小説情報一覧を取得できる
- 小説情報一覧に含まれるコードを利用すれば、小説の中身が取得できる
Clean Architectureとは
ネットにいくらでも転がっているので割愛。
今回はRobert C. MartinさんのClean Architecture本を参考にした。
クラス設計をしていく上で気になったこと
疑問その1
Webから取得したレスポンスデータを処理してドメインモデルに変換するクラスはどこにあるべきなのか
結論
円の内側のレイヤーは外側レイヤーを知るべきではない。 内側のレイヤーは一番変えてはいけない（変わらない）レイヤー= domain層 のため、externalはdomainを知っていてよいが、domainはexternalを知ってはいけない。そのためexternal層でレスポンスデータを処理し、ドメインモデルを生成する。
疑問その2
リポジトリを知ってはいけないとすると、ドメインで通信処理がしたくなったときどうすればよいのか
結論
インタフェースをかませるしかない。インターフェース自体の置き場所は、「ドメインは外側を知らない」ルールのため、ドメイン内に置く。
疑問その3
genreは101,102,201などが返却される。
この値は101=異世界[恋愛], 102=現実世界[恋愛]などと対応している。101の値などは基本利用しないため、レスポンスデータからドメインモデルに変換する際に置換して保持すべきではないか
結論
実際の業務に合わせた方がよいと思う。今回の場合は101で実際に管理しているため、ドメイン側でgenreName()を用意し、そこで対応表に合わせた名前を返すようにする。
感想
下位レイヤーと上位レイヤーの考え方が今までと異なっていた(業務ロジックが上で、通信周りは下のイメージだった)ので、そこの切り替えに時間がかかった気がする。
完成してみるとドメインがきれいに切り離されていていい感じ。
