アプリのための「レイヤー化」アーキテクチャ / Droid Meetup 2019-03

アプリのための  「レイヤー化」アーキテクチャ 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 レスポンスなど
対策: 例外的に機能横断的なものを管理するパッケージを⽤意

ドメイン特有ではあるが、ロジックは単純宣⾔的なコードが多い要素の定義が中⼼であり、実装関連のコードは⼊らない横断的機能のパッケージの特徴

パッケージ構成

結論

「レイヤー化」されたパッケージ構成を  適⽤した

ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ

アプリのための「レイヤー化」アーキテクチャ / Droid Meetup 2019-03

アプリのための「レイヤー化」アーキテクチャ / Droid Meetup 2019-03

More Decks by Motoi Washida

Other Decks in Programming

Featured

Transcript