Kotlin Multiplatformで考えるクリーンアーキテクチャ

Transcript

1. Kotlin Multiplatformで 考える クリーンアーキテクチャ horitamon • 2024 年 7月 8日

   After Kotlin Fest 2024 LT Night ＠Sansan

2. 自己紹介 堀 多聞 - horitamon 2020/9〜2024/5 株式会社Voicy Androidエンジニア7年目 登壇: ・DroidKaigi

   2022 ・iOSDC 2023 X: @horitamon

3. https://iosdc.jp/2024/

4. 本日の流れ Kotlin Multiplatformの 導入で考える クリーンアーキテクチャ 1. クリーンアーキテクチャとは 結局何なのか？ 2. Kotlin

   Multiplatform（KMP）の 概要 3. 課題をクリーンアーキテクチャの 考え方で解決する

5. 今年話そうとしてました https://fortee.jp/kotlin-fest-2024/proposal/c8ec4c4c-206c-4f18-b5a5-7552c49877f7 https://fortee.jp/kotlin-fest-2024/proposal/c0b2c96d-5d09-4612-ba53-3e9ea22e5a5b

6. 「クリーンアーキテクチャ」 知ってますか？

7. None
8. None

9. 私はこう思っていました。 • この図は「クリーンアーキテクチャ」という 特定のアーキテクチャを説明する図である • 「クリーンアーキテクチャ」を実現することとは、 この図のようにクラスを定義して 実装していくことである

10. 勘違いしてました。

11. 本文の図の説明を読んでみると… これらのすべてのアーキテクチャを単一の実行可能なアイデア に統合したものである → 複数のアーキテクチャの共通項を示しているだけ！ 図は共通項を示している

12. 同じ章でこうも言ってる したがって、この4つ以外にも必要なものはあるだろう。 この4つ以外に認めないというルールはない。 → 4つに分けることが「クリーンアーキテクチャ」を 　実現することではない！

13. ではこの本は 何を言っているんだろう ※予防線を張りますが私の感想です

14. 「ビジネス」より 「手段」は不安定

15. 例えば、名刺を管理する事業だと…

16. 最初は棚で管理するところから初まり… 保存する 取り出す

17. スーパー名刺管理アドバイザー提供事業や… 預ける 受け取る

18. PCで使えるツールになったりするかも 写真保存 画面で確認

19. 「どう実現するか」が変化している 写真保存 画面で確認

20. 「手段」は不安定である • ビジネスを実現する手段は多様で、頻繁に変化する • コンサル事業かもしれないし、SaaS事業かもしれない • ソフトウェアとして提供することに固まっても ライブラリはよく更新されるし、よく入れ替えるし UIもよく変わる •

    これら手段の変更の影響を ビジネスが受けないようにしたい

21. 「ビジネス」に「手段」が 依存するようにしよう

22. 名刺を管理する事業でいう「ビジネス」は…

23. 名刺の情報を預かり、それを確認できること 名刺情報を預かる 名刺情報を確認する

24. どういった手段でも提供価値は変わらない 名刺情報を預かる 名刺情報を確認する

25. サービス目線では手段を意識しないし 名刺情報を預かる 名刺情報を確認する

26. 手段は提供価値を意識して実装する 名刺情報を預かる 名刺情報を確認する

27. このinterfaceを定義して、それに依存しよう 名刺情報を預かる 名刺情報を確認する

28. None

29. 名刺情報を預かる 名刺情報を確認する

30. 名刺情報を預かる 名刺情報を確認する

31. 内側の概念に、外側から依存する • 一番中心をビジネスとして実現したい概念とする • 実現したいことを実現するための 詳細な手段が外側の概念 • 詳細な手段はビジネスが何をしたいのかを知るが、 ビジネスはどう実現するのかの詳細を知らない •

    この関係性をきれいに実現すると 変更に強く、テストがしやすいソフトになる このルールを一貫して守ろうねという話

32. とてもわかりやすい説明・資料 • 世界一わかりやすいClean Architecture - nuits.jp blog • 擬人化で完全に理解するクリーンアーキテクチャ -

    Speaker Deck • クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net

33. Kotlin Multiplatformとは？

34. iOS/Webでも動かせるKotlin FW https://www.jetbrains.com/ja-jp/kotlin-multiplatform/

35. プラットフォームごとに 処理が違うときは？

36. 例えば… • デバイス情報を取得する • ハードウェア（カメラ、センサー、認証など）を 操作する • サードパーティライブラリを使用する →プラットフォームごとに処理が異なる部分を 　書き分けたい

37. expect / actual https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...

38. 実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...

39. ただ、課題もある

40. 全部Kotlinで書かないといけない • Android以外のプラットフォーム固有機能を使う処理を Kotlinで書くことになる • Androidエンジニアは機能理解が足りなくて難しい • その他のエンジニアはKotlin / KMPに慣れてなくて難しい

41. 依存解決に手間がかかる • サードパーティライブラリ利用時に iOSの依存解決でCocoaPodsを使うとクセがあった • 独自実装のライブラリをKMP層から直接依存するには Submoduleやライブラリ化が必要

42. そこで クリーンアーキテクチャの 考え方

43. KMPにinterfaceを定義して、実装はPF側で https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#dependency-injection...

44. 実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#different-entry-points

45. None

46. この構成でうれしいポイント • 各プラットフォームの処理をそれぞれの言語で 実装できる →分担しやすい • より外側のレイヤーの修正 （実装、ライブラリのアップデートや入れ替え）時に ビジネスロジックに変更がなければ KMPモジュールの修正が不要

    →より中心に近いレイヤーの処理が守られる

47. まとめ

48. クリーンアーキテクチャの内容は どんな設計にも適用できる考え方 • クリーンアーキテクチャは特定の形があるものではない • 中心の概念に向かって依存関係をつくるというルールを一 貫して守ろうという話 • KMPを実装する場合、 プラットフォーム固有部分の依存性を整理すると

    変更に強い設計にできる

49. Thank you!