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
アプリのための「レイヤー化」アーキテクチャ / Droid Meetup 2019-03
Search
Motoi Washida
March 20, 2019
Programming
0
2.5k
アプリのための「レイヤー化」アーキテクチャ / Droid Meetup 2019-03
Motoi Washida
March 20, 2019
Tweet
Share
More Decks by Motoi Washida
See All by Motoi Washida
Material Design の社内勉強会を行った / Android Engineer Design 1
wm3
1
190
API仕様書から自前でコード生成して運用した話 / DroidKaigi 2018 Reject Conference
wm3
0
900
apply() 要らなくない?
wm3
2
1.4k
Firebase Analytics で 画像ロードのパフォーマンス を測定し、改善をした話
wm3
2
1.5k
Tunnel 社内勉強会 Swift の紹介
wm3
0
300
iOS の Reactive 系ライブラリ
wm3
1
930
Other Decks in Programming
See All in Programming
overlayPreferenceValue で実現する ピュア SwiftUI な AdMob ネイティブ広告
uhucream
0
170
Breaking Up with Big ViewModels — Without Breaking Your Architecture (droidcon Berlin 2025)
steliosf
PRO
1
350
CSC305 Lecture 02
javiergs
PRO
1
260
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
240
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
750
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
630
高度なUI/UXこそHotwireで作ろう Kaigi on Rails 2025
naofumi
4
3.6k
『毎日の移動』を支えるGoバックエンド内製開発
yutautsugi
2
210
CSC509 Lecture 05
javiergs
PRO
0
300
開発生産性を上げるための生成AI活用術
starfish719
1
200
Six and a half ridiculous things to do with Quarkus
hollycummins
0
130
Domain-centric? Why Hexagonal, Onion, and Clean Architecture Are Answers to the Wrong Question
olivergierke
1
570
Featured
See All Featured
Building an army of robots
kneath
306
46k
Code Review Best Practice
trishagee
72
19k
Typedesign – Prime Four
hannesfritz
42
2.8k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Agile that works and the tools we love
rasmusluckow
331
21k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Context Engineering - Making Every Token Count
addyosmani
5
200
How GitHub (no longer) Works
holman
315
140k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
960
Unsuck your backbone
ammeep
671
58k
Transcript
アプリのための 「レイヤー化」アーキテクチャ RoomClip 株式会社 鷲⽥ 基
⾃⼰紹介
⾃⼰紹介 名前: 鷲⽥ 基 Twitter: @wm3 DroidKaigi スタッフ (Webサイト) RoomClip
アプリエンジニア
RoomClipアプリのコードの パッケージ構成の話をします
皆さんに質問
パッケージをどの⽅向 で分割してますか?
アーキテクチャーの要素で分割
機能で分割
機能+アーキテクチャーの要素で分割
機能+アーキテクチャーの要素で分割2
RoomClip の場合
当初のパッケージ構成
当初のMVCパッケージ構成
models, views, controllers で分離 アーキテクチャーの要素による分類 クラス種類によるサブ階層 models/entities, controllers/activities など 当初のMVCパッケージ構成
課題
問題: あらゆる所で使われる 巨⼤エンティティ
例: 写真エンティティ
プロパティが30くらい 写真関連の属性が全部⼊っている ユーザーがその写真をいいねしたかとか 写真情報を渡す時はいつも使う 例: 写真エンティティ
すると
⼀部しか使わない属性が増える 属性に正しい値を⼊れなくなる 例: IDしか正しい値が⼊っていない 正しい値が⼊っているとは限らな い! あらゆる所で使われる巨⼤エンティティ
すると 例えば新機能開発時に
属性値が正しいのか分からない ソース追ったり実⾏しないと確認できない 新しい画⾯で使って良いのかわか らない あらゆる所で使われる巨⼤エンティティ
この属性 使っていいの?
問題: ⼀つのパッケージに クラスがずらっと並ぶ
単純に⾒通しが悪い クラスの公開範囲がわからない あらゆる所で使う事を想定したクラス ⼀箇所でしか使わないクラス ⼀つのパッケージにクラスがずらっと並ぶ
このクラス 使っていいの?
現在のパッケージ構成
現在の基本構成
レイヤー化されたパッケージ構成 ⼀部の例外除き逆⽅向の「依存」を許容しない 抽象的な要素は極⼒導⼊しない interface を集めたパッケージなど パッケージ構成の⽅針
共通パッケージ common.*, infrastructure.*
アプリの機能に依存しないコード ユーザー関連機能とかは基本⼊れない common 社内の別アプリで使いま わせるレベル design、api、trackingなど infrastructure 公開可能なレベル いつも使う utility
など 共通パッケージ(common, infrastructure)
各機能のパッケージ app.*
アプリ特有のロジック 写真投稿、ホーム、など 機能毎にパッケージを分離 app.photo.post、app.social.home、など 各機能のパッケージ(app)
これだけだと 問題がある
パッケージ構成
パッケージ構成
問題: app の各パッケージが ⼤きくなる
コード全体が⼤きいのは仕⽅がな い ただし他の機能からの⼊り⼝は最 ⼩限にしたい 例: 投稿画⾯とかは遷移機能だけ公開すれば良い app 以下のパッケージが⼤きくなる
app/*/external 公開パッケージ app/*/internal ⾮公開パッケージ ほとんどのクラスは internal にする 対策: external/internal分離
問題: 横断的に管理したい 機能がある
機能横断した⽅が良いコードがある URL Handlerや計測 コード⽣成しているクラスがある API 関係 (参考: 去年のDroidKaigiのRejectConf) 横断的に管理したい機能がある
app/system/* URL Handlerなど 他の app パッケージと違い基本 external generated API レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意
ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
パッケージ構成
結論
「レイヤー化」された パッケージ構成を 適⽤した
ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ