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
Back to the Future: Let me tell you about the ACP protocol
terhechte
0
120
議事録の要点整理を自動化! サーバレス Bot 構築術
penpeen
3
1.6k
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1k
Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム
giginet
PRO
0
1.6k
プログラマのための作曲入門
cheebow
0
510
プログラミングどうやる? ~テスト駆動開発から学ぶ達人の型~
a_okui
0
190
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
1
560
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
2
1.5k
パフォーマンスチューニングで Web 技術を深掘り直す
progfay
18
4.8k
NetworkXとGNNで学ぶグラフデータ分析入門〜複雑な関係性を解き明かすPythonの力〜
mhrtech
3
930
10年もののAPIサーバーにおけるCI/CDの改善の奮闘
mbook
0
670
Current States of Java Web Frameworks at JCConf 2025
kishida
0
560
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
A Tale of Four Properties
chriscoyier
160
23k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Thoughts on Productivity
jonyablonski
70
4.8k
How to Think Like a Performance Engineer
csswizardry
27
2k
GitHub's CSS Performance
jonrohan
1032
460k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
How STYLIGHT went responsive
nonsquared
100
5.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Facilitating Awesome Meetings
lara
56
6.6k
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