Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kotlin Multiplatformで考えるクリーンアーキテクチャ
Search
horitamon
July 08, 2024
Programming
0
260
Kotlin Multiplatformで考えるクリーンアーキテクチャ
https://sansan.connpass.com/event/320810/
horitamon
July 08, 2024
Tweet
Share
More Decks by horitamon
See All by horitamon
スタートアップ企業のフェーズ転換期を乗り越えるためのリアーキテクト戦略
horitamon
0
570
ActでGithub Actionsの動作確認をする
horitamon
0
1.3k
Bitrise Pipelinesを使って リリース作業を効率化する
horitamon
0
67
コルーチンを使って処理の見通しをよくする
horitamon
2
2.3k
解決むずかったバグ3選
horitamon
0
460
「OK Google」でアプリの機能を呼び出してみる
horitamon
0
1.5k
Other Decks in Programming
See All in Programming
『実践MLOps』から学ぶ DevOps for ML
nsakki55
2
410
予防に勝る防御なし(2025年版) - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHP Conference Fukuoka 2025
twada
PRO
39
12k
JJUG CCC 2025 Fall: Virtual Thread Deep Dive
ternbusty
3
430
Eloquentを使ってどこまでコードの治安を保てるのか?を新人が考察してみた
itokoh0405
0
3.2k
TVerのWeb内製化 - 開発スピードと品質を両立させるまでの道のり
techtver
PRO
3
1.1k
PHPライセンス変更の議論を通じて学ぶOSSライセンスの基礎
matsuo_atsushi
0
150
最新のDirectX12で使えるレイトレ周りの機能追加について
projectasura
0
250
モビリティSaaSにおけるデータ利活用の発展
nealle
0
460
Java_プロセスのメモリ監視の落とし穴_NMT_で見抜けない_glibc_キャッシュ問題_.pdf
ntt_dsol_java
0
210
GraalVM Native Image トラブルシューティング機能の最新状況(2025年版)
ntt_dsol_java
0
140
Flutterチームから作る組織の越境文化
findy_eventslides
0
110
関数の挙動書き換える
takatofukui
4
660
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
670
GraphQLとの向き合い方2022年版
quramy
49
14k
Building Applications with DynamoDB
mza
96
6.8k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The Pragmatic Product Professional
lauravandoore
36
7k
Stop Working from a Prison Cell
hatefulcrawdad
272
21k
Bash Introduction
62gerente
615
210k
Balancing Empowerment & Direction
lara
5
750
Visualization
eitanlees
150
16k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
Transcript
Kotlin Multiplatformで 考える クリーンアーキテクチャ horitamon • 2024 年 7月 8日
After Kotlin Fest 2024 LT Night @Sansan
自己紹介 堀 多聞 - horitamon 2020/9〜2024/5 株式会社Voicy Androidエンジニア7年目 登壇: ・DroidKaigi
2022 ・iOSDC 2023 X: @horitamon
https://iosdc.jp/2024/
本日の流れ Kotlin Multiplatformの 導入で考える クリーンアーキテクチャ 1. クリーンアーキテクチャとは 結局何なのか? 2. Kotlin
Multiplatform(KMP)の 概要 3. 課題をクリーンアーキテクチャの 考え方で解決する
今年話そうとしてました https://fortee.jp/kotlin-fest-2024/proposal/c8ec4c4c-206c-4f18-b5a5-7552c49877f7 https://fortee.jp/kotlin-fest-2024/proposal/c0b2c96d-5d09-4612-ba53-3e9ea22e5a5b
「クリーンアーキテクチャ」 知ってますか?
None
None
私はこう思っていました。 • この図は「クリーンアーキテクチャ」という 特定のアーキテクチャを説明する図である • 「クリーンアーキテクチャ」を実現することとは、 この図のようにクラスを定義して 実装していくことである
勘違いしてました。
本文の図の説明を読んでみると… これらのすべてのアーキテクチャを単一の実行可能なアイデア に統合したものである → 複数のアーキテクチャの共通項を示しているだけ! 図は共通項を示している
同じ章でこうも言ってる したがって、この4つ以外にも必要なものはあるだろう。 この4つ以外に認めないというルールはない。 → 4つに分けることが「クリーンアーキテクチャ」を 実現することではない!
ではこの本は 何を言っているんだろう ※予防線を張りますが私の感想です
「ビジネス」より 「手段」は不安定
例えば、名刺を管理する事業だと…
最初は棚で管理するところから初まり… 保存する 取り出す
スーパー名刺管理アドバイザー提供事業や… 預ける 受け取る
PCで使えるツールになったりするかも 写真保存 画面で確認
「どう実現するか」が変化している 写真保存 画面で確認
「手段」は不安定である • ビジネスを実現する手段は多様で、頻繁に変化する • コンサル事業かもしれないし、SaaS事業かもしれない • ソフトウェアとして提供することに固まっても ライブラリはよく更新されるし、よく入れ替えるし UIもよく変わる •
これら手段の変更の影響を ビジネスが受けないようにしたい
「ビジネス」に「手段」が 依存するようにしよう
名刺を管理する事業でいう「ビジネス」は…
名刺の情報を預かり、それを確認できること 名刺情報を預かる 名刺情報を確認する
どういった手段でも提供価値は変わらない 名刺情報を預かる 名刺情報を確認する
サービス目線では手段を意識しないし 名刺情報を預かる 名刺情報を確認する
手段は提供価値を意識して実装する 名刺情報を預かる 名刺情報を確認する
このinterfaceを定義して、それに依存しよう 名刺情報を預かる 名刺情報を確認する
None
名刺情報を預かる 名刺情報を確認する
名刺情報を預かる 名刺情報を確認する
内側の概念に、外側から依存する • 一番中心をビジネスとして実現したい概念とする • 実現したいことを実現するための 詳細な手段が外側の概念 • 詳細な手段はビジネスが何をしたいのかを知るが、 ビジネスはどう実現するのかの詳細を知らない •
この関係性をきれいに実現すると 変更に強く、テストがしやすいソフトになる このルールを一貫して守ろうねという話
とてもわかりやすい説明・資料 • 世界一わかりやすいClean Architecture - nuits.jp blog • 擬人化で完全に理解するクリーンアーキテクチャ -
Speaker Deck • クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net
Kotlin Multiplatformとは?
iOS/Webでも動かせるKotlin FW https://www.jetbrains.com/ja-jp/kotlin-multiplatform/
プラットフォームごとに 処理が違うときは?
例えば… • デバイス情報を取得する • ハードウェア(カメラ、センサー、認証など)を 操作する • サードパーティライブラリを使用する →プラットフォームごとに処理が異なる部分を 書き分けたい
expect / actual https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...
実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#expected-and-actual...
ただ、課題もある
全部Kotlinで書かないといけない • Android以外のプラットフォーム固有機能を使う処理を Kotlinで書くことになる • Androidエンジニアは機能理解が足りなくて難しい • その他のエンジニアはKotlin / KMPに慣れてなくて難しい
依存解決に手間がかかる • サードパーティライブラリ利用時に iOSの依存解決でCocoaPodsを使うとクセがあった • 独自実装のライブラリをKMP層から直接依存するには Submoduleやライブラリ化が必要
そこで クリーンアーキテクチャの 考え方
KMPにinterfaceを定義して、実装はPF側で https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#dependency-injection...
実装例 https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-connect-to-apis.html#different-entry-points
None
この構成でうれしいポイント • 各プラットフォームの処理をそれぞれの言語で 実装できる →分担しやすい • より外側のレイヤーの修正 (実装、ライブラリのアップデートや入れ替え)時に ビジネスロジックに変更がなければ KMPモジュールの修正が不要
→より中心に近いレイヤーの処理が守られる
まとめ
クリーンアーキテクチャの内容は どんな設計にも適用できる考え方 • クリーンアーキテクチャは特定の形があるものではない • 中心の概念に向かって依存関係をつくるというルールを一 貫して守ろうという話 • KMPを実装する場合、 プラットフォーム固有部分の依存性を整理すると
変更に強い設計にできる
Thank you!