マルチモジュール化

[taratara10]

https://twitter.com/the_uhooi/status/1561347192753127426?s=20&t=rrmE2LwiyLBD-aoMzCLTDA https://twitter.com/the_uhooi/status/1561344959642742784?s=20&t=rrmE2LwiyLBD-aoMzCLTDA

マルチモジュールってちゃんと設計しないとめちゃ複雑になって逆に可読性が落ちるし、依存関係がカッチリ決まるから雑にアプリを作れなくなって開発効率が下がってしまう モチベ・設計スキル・アプリの規模 次第ではやらない選択もありだと思う

ガチガチに設計してマルチモジュールしたいな 設計スキルを高めたい

• https://droidkaigi.github.io/codelab-2020/ja/index.html#0

[taratara10]

• droidKaigi
  • https://github.com/DroidKaigi/conference-app-2022
• nowInAndroid
  • https://github.com/android/nowinandroid
• Doskoi
  • https://github.com/Naoki-Hidaka/GitHubClientForJetpackCompose

[taratara10]

├app ├ feature ├ core │　├data │　├di │　├datasource │　├repository │　├usecase

[taratara10]

あんま細分化したくないな～ https://zenn.dev/chooyan/articles/eefc76dbd2ba25

• diって、各moduleで@Singletoneを提供すれば事足りる、、、？
  • 低凝集なので、単一moduleが良さそう
• domain と data どうしよ
  • 必ず詰め替える必要があるかと言えばそうではない
  • module毎にobjectを詰め替えろは過激派
  • ので、共通が良さそう
    • 共通は責務の分離が難しくなるが？
    • uiStateをdomainと捉えるなら、repository -> dataの依存は不要
• usecaseは現状必要ないけど作るか悩ましい
  • アプリTとサーバーが分断されてる場合は詰め替えは必須
  • 個人開発はいいかな～
  • WearOS展開とか考慮するなら、サーバーはgeneralにしときたい
• business を作りたい
  • その意味では解決したい問題を明確にする意味でbusinessはアリ
• reoisitoryの名前空間がかぶってる
  • nowInではrepositoryないのか
  • data層かな

├app
├ feature
├ core
│　├data
│　│  ├repositoryImpl
│　│  ├api
│　│  └database
│　├di
│　├model(data class with no sub module)
│　└business
│　  ├repository
│　  └usecase

[taratara10]

• dummyどこにつくろ
  • repositoryImplだけでいい
  • api, databaseは実装不要
  • と思ったけど、コンパイルエラーなるか
  • もしかして、DIでif (BuildConfig.flavor == "dummy) DummyRepository() else EntityRepository()で天才！？
  • これにすればinterface dummy実装漏れがなくなるな
    • 不要なコードが入るな～～～～～
    • クソデカ無駄コードを入れますか？と問われるとアプリサイズ小さくするために入れない方が良さそう
• てかsrc配下でいいのでは？
  • core/data/src/main,
  • core/data/src/dummy

https://github.com/android/nowinandroid/tree/main/core/network/src

[taratara10]

• [ ] ktsにしたい気もする

[taratara10]

useCaseはkotlin pureな気もするけど、uiStateへの詰め替えも、、、うーんテスト容易性下がるからviewModelでやるべき？

[taratara10]

core:business vs core:domain

domainな気がする　オニオンの図！？

[taratara10]

• すべてはdomainに依存してるので、model分ける必要なくない？
  • exceptionとかはdomainと関係ないので、関心の分離すべき

[taratara10]

featureって細かく切るべき？ っぽいけど、composeのnavigationとか分かってなさすぎなので、いったんcore分割でおｋ

[taratara10]

gradleって、libで一括管理できるっぽいな

[taratara10]

46

47

に引き継いだ