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.4k
アプリのための「レイヤー化」アーキテクチャ / 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
160
API仕様書から自前でコード生成して運用した話 / DroidKaigi 2018 Reject Conference
wm3
0
810
apply() 要らなくない?
wm3
2
1.2k
Firebase Analytics で 画像ロードのパフォーマンス を測定し、改善をした話
wm3
2
1.3k
Tunnel 社内勉強会 Swift の紹介
wm3
0
250
iOS の Reactive 系ライブラリ
wm3
1
880
Other Decks in Programming
See All in Programming
Git Lint
bkuhlmann
4
750
Node.js v22 で変わること
yosuke_furukawa
PRO
9
3.5k
AWS CDKコントリビュートTIPS / aws-cdk-contribution-tips
gotok365
2
200
Rethinking UI building strategies @ SFI 2024
letelete
0
270
FigmaとPHPで作る1ミリたりとも表示崩れしない最強の帳票印刷ソリューション
ttskch
43
19k
SwiftUIで使いやすいToastの作り方 / How to build a Toast system which is easy to use in SwiftUI
lovee
3
150
dbtのドメイン分割による データ基盤の改善とDigdagとの連携
sakama
0
350
Blue/Greenデプロイの導入による 運用フローの改善
kudoas
1
380
デフォルトにして至高、RubyMineの大好きな所
ruzia
0
400
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
27
8.3k
Java 22 Overview
kishida
1
180
Compose-View Interop in Practice (mDevCamp 2024)
stewemetal
0
140
Featured
See All Featured
The Language of Interfaces
destraynor
151
23k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
6
1.5k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
BBQ
matthewcrist
80
8.8k
Building a Modern Day E-commerce SEO Strategy
aleyda
17
6.4k
In The Pink: A Labor of Love
frogandcode
138
21k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
GraphQLとの向き合い方2022年版
quramy
32
12k
We Have a Design System, Now What?
morganepeng
43
6.8k
Gamification - CAS2011
davidbonilla
76
4.6k
Building an army of robots
kneath
300
41k
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 レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意
ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
パッケージ構成
結論
「レイヤー化」された パッケージ構成を 適⽤した
ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ