あらためてModularization learning journeyを読んで頭の整理
rmakiyamaザッと読んでなるほどとなってたけど改めて読んで脳内を整理するスレ
rmakiyama最初にこのドキュメントにけるモジュール化について下記のように書いてる。
Modularization is the practice of breaking the concept of a monolithic, one-module codebase into loosely coupled, self contained modules.
モノリシックなものを、疎結合で自己完結モジュールにすると読めそう。
Overviewに書いてるだけあって、疎結合にすることは大きな目的のひとつになりそう。
rmakiyamaまずはざっくり読む。
Benefits of modularizationにはモジュール化の利点が述べられている。
ここらへんはだいたい公式ドキュメントにもあるものと似てそう。
Android depevers側のドキュメントでは、モジュール化で"のみ"得られるものとして挙げられているもので、Modularization learning journeyに記載されているのはDynamic deliveryの文脈のみっぽい。
Modularization pitfallsはモジュール化の注意点について述べられている。
これも同様に公式ドキュメントにあるものとほぼ同等そう。
ここではあくまでも、一般的な話で、nowinandroidにおける方針の話ではなさそう。一部、Too many modulesという問題については、build-logicを使ってるよ、という話だけ書いてる。
Modularization strategyで具体的な戦略について。
最初に注意として下記の記述があって良い。アーキテクチャガイドでも書いてるね。
It’s important to note that there is no single modularization strategy that fits all projects. However, there are general guidelines that can be followed to ensure you maximize its benefits and minimize its downsides.
Androidアプリ開発におけるリファレンスリポジトリとしての立ち位置を目指してるので、基本的には一般的なガイドラインに沿って作られてそう。
いろんな技術書や設計周りの話でよくある、「低結合」「高凝集」を目指そうなという方針っぽい。
--
nowinandroidの場合は、大きくapp/feature/coreの3つのタイプのモジュールがある。
appはアプリのトップレベルで制御したいコード群って感じ。
featureは単一責任の原則に従って分割された機能のモジュール群。再利用についても考慮されている。また、featureモジュール同士の依存は禁止としている。むずいよね。
coreはモジュール間で共有する必要があるコードや、特定の依存関係を持つライブラリモジュールとされてる。coreが別のcoreモジュールに依存することは許容されている。依存の方向として、featureモジュールへの依存は避けるべきとしている。
どれもstrategyの項にあるように、「低結合」「高凝集」をベースとしてるね。
各モジュールは前述された通りの分割になっている。
core:datasotreとかは、DataStoreを使った永続化のモジュールになっていて、まさに特定の依存を持つライブラリとなってそう。実際にandroidx.datastoreに依存しているのはdatasotreのモジュールだけ。
Modularization in Now in Android
nowinandroid自体は比較的小さめだけど、実際のアプリに近いモジュール分割のパターン紹介の意味合いも含めて作られているっぽい。ビックテックを除いて、結構あてはめやすいアプリは多そう。
もちろんここでも、唯一の正解はないよの話もある。大事。
事前に計画を立てること、目的や課題、将来の進化やリスクを考慮に入れて、最適なものを模索するのが大事。
rmakiyamaあらためてざっと読んだので気になるところを深ぼるぞ