Tweet
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!