Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Kotlin Multiplatformで 考える クリーンアーキテクチャ horitamon • 2024 年 7月 8日 After Kotlin Fest 2024 LT Night @Sansan
Slide 2
Slide 2 text
自己紹介 堀 多聞 - horitamon 2020/9〜2024/5 株式会社Voicy Androidエンジニア7年目 登壇: ・DroidKaigi 2022 ・iOSDC 2023 X: @horitamon
Slide 3
Slide 3 text
https://iosdc.jp/2024/
Slide 4
Slide 4 text
本日の流れ Kotlin Multiplatformの 導入で考える クリーンアーキテクチャ 1. クリーンアーキテクチャとは 結局何なのか? 2. Kotlin Multiplatform(KMP)の 概要 3. 課題をクリーンアーキテクチャの 考え方で解決する
Slide 5
Slide 5 text
今年話そうとしてました https://fortee.jp/kotlin-fest-2024/proposal/c8ec4c4c-206c-4f18-b5a5-7552c49877f7 https://fortee.jp/kotlin-fest-2024/proposal/c0b2c96d-5d09-4612-ba53-3e9ea22e5a5b
Slide 6
Slide 6 text
「クリーンアーキテクチャ」 知ってますか?
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
私はこう思っていました。 ● この図は「クリーンアーキテクチャ」という 特定のアーキテクチャを説明する図である ● 「クリーンアーキテクチャ」を実現することとは、 この図のようにクラスを定義して 実装していくことである
Slide 10
Slide 10 text
勘違いしてました。
Slide 11
Slide 11 text
本文の図の説明を読んでみると… これらのすべてのアーキテクチャを単一の実行可能なアイデア に統合したものである → 複数のアーキテクチャの共通項を示しているだけ! 図は共通項を示している
Slide 12
Slide 12 text
同じ章でこうも言ってる したがって、この4つ以外にも必要なものはあるだろう。 この4つ以外に認めないというルールはない。 → 4つに分けることが「クリーンアーキテクチャ」を 実現することではない!
Slide 13
Slide 13 text
ではこの本は 何を言っているんだろう ※予防線を張りますが私の感想です
Slide 14
Slide 14 text
「ビジネス」より 「手段」は不安定
Slide 15
Slide 15 text
例えば、名刺を管理する事業だと…
Slide 16
Slide 16 text
最初は棚で管理するところから初まり… 保存する 取り出す
Slide 17
Slide 17 text
スーパー名刺管理アドバイザー提供事業や… 預ける 受け取る
Slide 18
Slide 18 text
PCで使えるツールになったりするかも 写真保存 画面で確認
Slide 19
Slide 19 text
「どう実現するか」が変化している 写真保存 画面で確認
Slide 20
Slide 20 text
「手段」は不安定である ● ビジネスを実現する手段は多様で、頻繁に変化する ● コンサル事業かもしれないし、SaaS事業かもしれない ● ソフトウェアとして提供することに固まっても ライブラリはよく更新されるし、よく入れ替えるし UIもよく変わる ● これら手段の変更の影響を ビジネスが受けないようにしたい
Slide 21
Slide 21 text
「ビジネス」に「手段」が 依存するようにしよう
Slide 22
Slide 22 text
名刺を管理する事業でいう「ビジネス」は…
Slide 23
Slide 23 text
名刺の情報を預かり、それを確認できること 名刺情報を預かる 名刺情報を確認する
Slide 24
Slide 24 text
どういった手段でも提供価値は変わらない 名刺情報を預かる 名刺情報を確認する
Slide 25
Slide 25 text
サービス目線では手段を意識しないし 名刺情報を預かる 名刺情報を確認する
Slide 26
Slide 26 text
手段は提供価値を意識して実装する 名刺情報を預かる 名刺情報を確認する
Slide 27
Slide 27 text
このinterfaceを定義して、それに依存しよう 名刺情報を預かる 名刺情報を確認する
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
名刺情報を預かる 名刺情報を確認する
Slide 30
Slide 30 text
名刺情報を預かる 名刺情報を確認する
Slide 31
Slide 31 text
内側の概念に、外側から依存する ● 一番中心をビジネスとして実現したい概念とする ● 実現したいことを実現するための 詳細な手段が外側の概念 ● 詳細な手段はビジネスが何をしたいのかを知るが、 ビジネスはどう実現するのかの詳細を知らない ● この関係性をきれいに実現すると 変更に強く、テストがしやすいソフトになる このルールを一貫して守ろうねという話
Slide 32
Slide 32 text
とてもわかりやすい説明・資料 ● 世界一わかりやすいClean Architecture - nuits.jp blog ● 擬人化で完全に理解するクリーンアーキテクチャ - Speaker Deck ● クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net
Slide 33
Slide 33 text
Kotlin Multiplatformとは?
Slide 34
Slide 34 text
iOS/Webでも動かせるKotlin FW https://www.jetbrains.com/ja-jp/kotlin-multiplatform/
Slide 35
Slide 35 text
プラットフォームごとに 処理が違うときは?
Slide 36
Slide 36 text
例えば… ● デバイス情報を取得する ● ハードウェア(カメラ、センサー、認証など)を 操作する ● サードパーティライブラリを使用する →プラットフォームごとに処理が異なる部分を 書き分けたい
Slide 37
Slide 37 text
expect / actual https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...
Slide 38
Slide 38 text
実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...
Slide 39
Slide 39 text
ただ、課題もある
Slide 40
Slide 40 text
全部Kotlinで書かないといけない ● Android以外のプラットフォーム固有機能を使う処理を Kotlinで書くことになる ● Androidエンジニアは機能理解が足りなくて難しい ● その他のエンジニアはKotlin / KMPに慣れてなくて難しい
Slide 41
Slide 41 text
依存解決に手間がかかる ● サードパーティライブラリ利用時に iOSの依存解決でCocoaPodsを使うとクセがあった ● 独自実装のライブラリをKMP層から直接依存するには Submoduleやライブラリ化が必要
Slide 42
Slide 42 text
そこで クリーンアーキテクチャの 考え方
Slide 43
Slide 43 text
KMPにinterfaceを定義して、実装はPF側で https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#dependency-injection...
Slide 44
Slide 44 text
実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#different-entry-points
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
この構成でうれしいポイント ● 各プラットフォームの処理をそれぞれの言語で 実装できる →分担しやすい ● より外側のレイヤーの修正 (実装、ライブラリのアップデートや入れ替え)時に ビジネスロジックに変更がなければ KMPモジュールの修正が不要 →より中心に近いレイヤーの処理が守られる
Slide 47
Slide 47 text
まとめ
Slide 48
Slide 48 text
クリーンアーキテクチャの内容は どんな設計にも適用できる考え方 ● クリーンアーキテクチャは特定の形があるものではない ● 中心の概念に向かって依存関係をつくるというルールを一 貫して守ろうという話 ● KMPを実装する場合、 プラットフォーム固有部分の依存性を整理すると 変更に強い設計にできる
Slide 49
Slide 49 text
Thank you!