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
みんなでプロポーザルを書いてみた
yuriko1211
0
260
弊社の「意識チョット低いアーキテクチャ」10選
texmeijin
5
24k
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
Jakarta EE meets AI
ivargrimstad
0
610
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
210
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.7k
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
860
CSC509 Lecture 12
javiergs
PRO
0
160
Quine, Polyglot, 良いコード
qnighy
4
640
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
220
.NET のための通信フレームワーク MagicOnion 入門 / Introduction to MagicOnion
mayuki
1
1.5k
色々なIaCツールを実際に触って比較してみる
iriikeita
0
330
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Unsuck your backbone
ammeep
668
57k
Side Projects
sachag
452
42k
How to Ace a Technical Interview
jacobian
276
23k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Building Adaptive Systems
keathley
38
2.3k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Embracing the Ebb and Flow
colly
84
4.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.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