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
テスト駆動Kaggle
isax1015
1
880
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
150
リバースエンジニアリング新時代へ! GhidraとClaude DesktopをMCPで繋ぐ/findy202507
tkmru
4
1.2k
What's new in AppKit on macOS 26
1024jp
0
170
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
450
Caude codeで爆速開発
codelynx
0
100
「App Intent」よくわからんけどすごい!
rinngo0302
1
120
バイブスあるコーディングで ~PHP~ 便利ツールをつくるプラクティス
uzulla
1
260
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
220
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
130
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
1
210
20250708_JAWS_opscdk
takuyay0ne
2
150
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
370
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
4 Signs Your Business is Dying
shpigford
184
22k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Side Projects
sachag
455
43k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
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