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
170
API仕様書から自前でコード生成して運用した話 / DroidKaigi 2018 Reject Conference
wm3
0
850
apply() 要らなくない?
wm3
2
1.3k
Firebase Analytics で 画像ロードのパフォーマンス を測定し、改善をした話
wm3
2
1.4k
Tunnel 社内勉強会 Swift の紹介
wm3
0
280
iOS の Reactive 系ライブラリ
wm3
1
910
Other Decks in Programming
See All in Programming
CI改善もDatadogとともに
taumu
0
110
ISUCON14公式反省会LT: 社内ISUCONの話
astj
PRO
0
180
ASP. NET CoreにおけるWebAPIの最新情報
tomokusaba
0
360
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
110
個人アプリを2年ぶりにアプデしたから褒めて / I just updated my personal app, praise me!
lovee
0
340
AWS Lambda functions with C# 用の Dev Container Template を作ってみた件
mappie_kochi
0
240
TokyoR116_BeginnersSession1_環境構築
kotatyamtema
0
110
『品質』という言葉が嫌いな理由
korimu
0
160
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
41
15k
DevinとCursorから学ぶAIエージェントメモリーの設計とMoatの考え方
itarutomy
1
640
技術を根付かせる / How to make technology take root
kubode
1
240
定理証明プラットフォーム lapisla.net
abap34
1
1.7k
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
950
For a Future-Friendly Web
brad_frost
176
9.5k
Side Projects
sachag
452
42k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Scaling GitHub
holman
459
140k
BBQ
matthewcrist
86
9.5k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.4k
Typedesign – Prime Four
hannesfritz
40
2.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
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 レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意
ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
パッケージ構成
結論
「レイヤー化」された パッケージ構成を 適⽤した
ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ