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
890
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
時間軸から考えるTerraformを使う理由と留意点
fufuhu
15
4.7k
Vue・React マルチプロダクト開発を支える Vite
andpad
0
110
テストカバレッジ100%を10年続けて得られた学びと品質
mottyzzz
2
580
Cache Me If You Can
ryunen344
2
660
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
110
私の後悔をAWS DMSで解決した話
hiramax
4
210
複雑なドメインに挑む.pdf
yukisakai1225
5
1.1k
Ruby Parser progress report 2025
yui_knk
1
430
速いWebフレームワークを作る
yusukebe
5
1.7k
go test -json そして testing.T.Attr / Kyoto.go #63
utgwkk
3
290
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
200
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
210
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Automating Front-end Workflow
addyosmani
1370
200k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
13k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Language of Interfaces
destraynor
161
25k
Imperfection Machines: The Place of Print at Facebook
scottboms
268
13k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
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 レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意
ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
パッケージ構成
結論
「レイヤー化」された パッケージ構成を 適⽤した
ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ