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
7
2.3k
設計にみる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.2k
デジタルアートのプラットフォームを開発してる話
r21nomi
1
520
How to notify Dataset changed for RecyclerView
r21nomi
2
1.5k
Let's make Photo Frame with Android Things
r21nomi
0
2.4k
アプリのUX向上のためにAWAがやってきたこと
r21nomi
0
910
Advanced Shared Element Transition
r21nomi
4
2.7k
Other Decks in Programming
See All in Programming
Googleのテストサイズを活用したテスト環境の構築
toms74209200
0
300
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.1k
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
160
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
d_endo
1
1.1k
シールドクラスをはじめよう / Getting Started with Sealed Classes
mackey0225
3
430
[PyCon Korea 2024 Keynote] 커뮤니티와 파이썬, 그리고 우리
beomi
0
120
Jakarta EE meets AI
ivargrimstad
0
120
僕がつくった48個のWebサービス達
yusukebe
20
17k
推し活としてのrails new/oshikatsu_ha_iizo
sakahukamaki
3
2k
Click-free releases & the making of a CLI app
oheyadam
2
100
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
5
3.7k
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1366
200k
Thoughts on Productivity
jonyablonski
67
4.3k
Documentation Writing (for coders)
carmenintech
65
4.4k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Designing the Hi-DPI Web
ddemaree
280
34k
Being A Developer After 40
akosma
86
590k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Adopting Sorbet at Scale
ufuk
73
9.1k
A Tale of Four Properties
chriscoyier
156
23k
Docker and Python
trallard
40
3.1k
A better future with KSS
kneath
238
17k
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