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
設計にみるAWA Androidアプリのこれまでとこれから
Search
Ryota Takemoto
March 12, 2018
Programming
6
2.4k
設計にみるAWA Androidアプリのこれまでとこれから
AWA Androidアプリの設計に関する過去と未来の話。
Ryota Takemoto
March 12, 2018
Tweet
Share
More Decks by Ryota Takemoto
See All by Ryota Takemoto
NEORT1周年の振り返りとこれからの話
r21nomi
0
1.3k
デジタルアートのプラットフォームを開発してる話
r21nomi
1
530
How to notify Dataset changed for RecyclerView
r21nomi
2
1.6k
Let's make Photo Frame with Android Things
r21nomi
0
2.5k
アプリのUX向上のためにAWAがやってきたこと
r21nomi
0
920
Advanced Shared Element Transition
r21nomi
4
2.9k
Other Decks in Programming
See All in Programming
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
620
テーブル定義書の構造化抽出して、生成AIでDWH分析を試してみた / devio2025tokyo
kasacchiful
0
280
Flutterで分数(Fraction)を表示する方法
koukimiura
0
140
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
360
Ktorで簡単AIアプリケーション
tsukakei
0
100
Go言語はstack overflowの夢を見るか?
logica0419
0
520
組込みだけじゃない!TinyGo で始める無料クラウド開発入門
otakakot
2
370
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
1.2k
CSC305 Lecture 09
javiergs
PRO
0
310
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
540
CSC509 Lecture 06
javiergs
PRO
0
270
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
460
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Code Reviewing Like a Champion
maltzj
526
40k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Scaling GitHub
holman
463
140k
Bash Introduction
62gerente
615
210k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Faster Mobile Websites
deanohume
310
31k
The Pragmatic Product Professional
lauravandoore
36
7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
YesSQL, Process and Tooling at Scale
rocio
173
15k
Six Lessons from altMBA
skipperchong
29
4k
Transcript
設計にみる AWA Androidアプリの これまでとこれから
新家 亮太 @AWA @r21nomi r21nomi Android / Creative Coding / Anime
本⽇話すこと
• これまでの設計 • その問題点 • これからの設計
これまでの設計
これまでの設計 ー ⽴ち上げ期 ー
• 2014.10〜 • Androidエンジニア 1 ~ 4⼈ • いわゆるMVC •
テストほぼゼロ
Model • DB, APIアクセス • ビジネスロジック Activity / Fragment •
プレゼンテーションロジック • ビジネスロジック
Model • DB, APIアクセス • ビジネスロジック Activity / Fragment •
プレゼンテーションロジック • ビジネスロジック
Model • DB, APIアクセス • ビジネスロジック Activity / Fragment •
プレゼンテーションロジック • ビジネスロジック ビジネスロジックを書く層が必要
Model • DB, APIアクセス • ビジネスロジック Activity / Fragment •
プレゼンテーションロジック • ビジネスロジック
Model •DB, APIアクセス •ビジネスロジック Activity / Fragment • プレゼンテーションロジック •
ビジネスロジック
Model •DB, APIアクセス •ビジネスロジック Activity / Fragment • プレゼンテーションロジック •
ビジネスロジック Modelの責務分割が必要
• ビジネスロジックを書く層をつくる • Modelの責務を分割
これまでの設計 ー 設計改善期 ー
• 2016.4〜 • Androidエンジニア 5⼈ • Clean Architecture Like •
data層のテスト充実
Model Activity / Fragment Before
DbClient / ApiClient Activity / Fragment Model UseCase Model Activity
/ Fragment Before After
DbClient / ApiClient • DB, APIアクセス Activity / Fragment •
プレゼンテーションロジック Model • DbClient / ApiClientの操作 UseCase • ビジネスロジック
DbClient / ApiClient • DB, APIアクセス Activity / Fragment •
プレゼンテーションロジック Model • DbClient / ApiClientの操作 UseCase • ビジネスロジック ビジネスロジックを書く層 ◎ Modelの責務を分割 ◎
DbClient / ApiClient • DB, APIアクセス Activity / Fragment •
プレゼンテーションロジック Model • DbClient / ApiClientの操作 UseCase • ビジネスロジック だが、まだまだ問題が
• 依然として巨⼤なActivity • ⼿続き型の処理多数 • 役割を失ったBase class • 修正困難な巨⼤クラス
結局、何が問題だったのか?
設計の擦り合わせをしていなかった
→ どこに何を書くべきかがバラバラ → 1クラスの責務が⼤きくなりすぎる → ⼀貫性のないコード 設計の擦り合わせをしていなかった
v2構想
ちゃんと設計の議論をして1から作る
• リーダビリティ シンプルに テストが書ける • テスタビリティ • メンテナビリティ 変更に強い 実装時に迷わない
設計は可視化しよう
新しい設計 ※3/12時点
• レイヤードアーキテクチャ + MVVM • CQRS
依存⽅向 app data ui domain data
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase
ViewModel CommandUseCase QueryUseCase ApiClient Repository Activity DataCommand DataQuery UI 画⾯データの管理
永続化データのI/F データ更新・取得処理の組み⽴て ビジネスロジック
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase
ApiClient • Retrofitインターフェース Repository
ApiClient • Retrofitインターフェース Repository • ローカルデータソースのインターフェース • DB, Pref, File,
Memory • 使う側はデータソースの種類を意識しない
APIはRepositoryではない?
“リポジトリを使う側からは、 ドメインモデルがあたかもメモリ上にコレク ションとして存在しているかのように⾒える” Martin Fowler
Repositoryを使う側はデータソースを 意識すべきではない
APIからデータを取得し、DBに保存 interface Repository<T> { fun fetch(): Single<T> fun save(data: T)
} repository.fetch() .doOnSuccess { repository.save(it) }
← データソース(API)を意識してる ← 保存先は知らない interface Repository<T> { fun fetch(): Single<T>
fun save(data: T) } repository.fetch() .doOnSuccess { repository.save(it) } repository.fetch() repository.save(it) APIからデータを取得し、DBに保存
interface Repository<T> { fun save(data: T) } apiClient.fetch() .doOnSuccess {
repository.save(it) } ← APIからの取得を意識する apiClient.fetch() repository.save(it) ← 保存先は知らない APIからデータを取得し、DBに保存
ApiClient • APIのインターフェース Repository • ローカルデータソースのインターフェース
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase
ViewModel DataQuery DataCommand ApiClient Repository Activity 依存⽅向 app data QueryUseCase
CommandUseCase Command? Query?
CQRS Command Query Responsibility Segregation
更新処理 → Command 取得処理 → Query
更新処理 → Command 取得処理 → Query • データの変更はしない • 値を返すだけ
• データを変更する • 値は返さない
「取得 × 更新」が複雑性を⽣む
ViewModel UseCase Single 更新・取得
ViewModel UseCase Single CommandUseCase QueryUseCase Completable Flowable ViewModel 更新・取得 取得
更新
CommandからQueryを分離し、 複雑性を緩和
データの流れ
ViewModel CommandUseCase ApiClient Repository Activity データの流れ app data QueryUseCase DataCommand
DataQuery
ViewModel CommandUseCase ApiClient Repository Activity データの流れ app data QueryUseCase DataCommand
DataQuery
ViewModel CommandUseCase ApiClient Repository Activity データの流れ app data QueryUseCase DataCommand
DataQuery
データの流れが単⼀⽅向に
まとめ
• レイヤー分けをし、責務を明確に • 更新と取得を分け、複雑性を緩和 • 曖昧にせずちゃんと議論して決める • 設計は可視化する 設計 進め⽅
Thank You @r21nomi r21nomi