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
830
apply() 要らなくない?
wm3
2
1.3k
Firebase Analytics で 画像ロードのパフォーマンス を測定し、改善をした話
wm3
2
1.4k
Tunnel 社内勉強会 Swift の紹介
wm3
0
270
iOS の Reactive 系ライブラリ
wm3
1
900
Other Decks in Programming
See All in Programming
Ethereum_.pdf
nekomatu
0
370
現場で役立つモデリング 超入門
masuda220
PRO
15
3.1k
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
53
34k
カスタムしながら理解するGraphQL Connection
yanagii
1
1.5k
ActiveSupport::Notifications supporting instrumentation of Rails apps with OpenTelemetry
ymtdzzz
1
170
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.2k
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
190
Outline View in SwiftUI
1024jp
1
280
Googleのテストサイズを活用したテスト環境の構築
toms74209200
0
300
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
440
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
160
AWS IaCの注目アップデート 2024年10月版
konokenj
3
3.2k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Writing Fast Ruby
sferik
627
61k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Building Applications with DynamoDB
mza
90
6.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
A better future with KSS
kneath
238
17k
The World Runs on Bad Software
bkeepers
PRO
65
11k
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 レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意
ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
パッケージ構成
結論
「レイヤー化」された パッケージ構成を 適⽤した
ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ