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

Transcript

1. アプリのための
 「レイヤー化」アーキテクチャ RoomClip 株式会社 鷲⽥ 基
   
2. ⾃⼰紹介
   
3. ⾃⼰紹介 名前: 鷲⽥ 基 Twitter: @wm3 DroidKaigi スタッフ (Webサイト) RoomClip アプリエンジニア
   
4. 
   
5. RoomClipアプリのコードの
 パッケージ構成の話をします
   
6. 
   
7. 皆さんに質問
   
8. パッケージをどの⽅向 で分割してますか?
   
9. アーキテクチャーの要素で分割
   
10. 機能で分割
    
11. 機能+アーキテクチャーの要素で分割
    
12. 機能+アーキテクチャーの要素で分割2
    
13. 
    
14. 
    
15. RoomClip の場合
    
16. 当初のパッケージ構成
    
17. 当初のMVCパッケージ構成
    
18. models, views, controllers で分離 アーキテクチャーの要素による分類 クラス種類によるサブ階層 models/entities, controllers/activities など 当初のMVCパッケージ構成
    
19. 課題
    
20. 問題:
 あらゆる所で使われる
 巨⼤エンティティ
    
21. 例: 写真エンティティ
    
22. プロパティが30くらい 写真関連の属性が全部⼊っている ユーザーがその写真をいいねしたかとか 写真情報を渡す時はいつも使う 例: 写真エンティティ
    
23. すると
    
24. ⼀部しか使わない属性が増える 属性に正しい値を⼊れなくなる 例: IDしか正しい値が⼊っていない 正しい値が⼊っているとは限らな い! あらゆる所で使われる巨⼤エンティティ
    
25. すると
 例えば新機能開発時に
    
26. 属性値が正しいのか分からない ソース追ったり実⾏しないと確認できない 新しい画⾯で使って良いのかわか らない あらゆる所で使われる巨⼤エンティティ
    
27. この属性
 使っていいの?
    
28. 問題:
 ⼀つのパッケージに
 クラスがずらっと並ぶ
    
29. 単純に⾒通しが悪い クラスの公開範囲がわからない あらゆる所で使う事を想定したクラス ⼀箇所でしか使わないクラス ⼀つのパッケージにクラスがずらっと並ぶ
    
30. このクラス
 使っていいの?
    
31. 現在のパッケージ構成
    
32. 現在の基本構成
    
33. レイヤー化されたパッケージ構成 ⼀部の例外除き逆⽅向の「依存」を許容しない 抽象的な要素は極⼒導⼊しない interface を集めたパッケージなど パッケージ構成の⽅針
    
34. 共通パッケージ common.*, infrastructure.*
    
35. アプリの機能に依存しないコード ユーザー関連機能とかは基本⼊れない common 社内の別アプリで使いま わせるレベル design、api、trackingなど infrastructure 公開可能なレベル いつも使う utility など 共通パッケージ(common, infrastructure)
    
36. 各機能のパッケージ app.*
    
37. アプリ特有のロジック 写真投稿、ホーム、など 機能毎にパッケージを分離 app.photo.post、app.social.home、など 各機能のパッケージ(app)
    
38. これだけだと
 問題がある
    
39. パッケージ構成
    
40. パッケージ構成
    
41. 問題:
 app の各パッケージが ⼤きくなる
    
42. コード全体が⼤きいのは仕⽅がな い ただし他の機能からの⼊り⼝は最 ⼩限にしたい 例: 投稿画⾯とかは遷移機能だけ公開すれば良い app 以下のパッケージが⼤きくなる
    
43. app/*/external 公開パッケージ app/*/internal ⾮公開パッケージ ほとんどのクラスは internal にする 対策: external/internal分離
    
44. 問題:
 横断的に管理したい
 機能がある
    
45. 機能横断した⽅が良いコードがある URL Handlerや計測 コード⽣成しているクラスがある API 関係 (参考: 去年のDroidKaigiのRejectConf) 横断的に管理したい機能がある
    
46. app/system/* URL Handlerなど 他の app パッケージと違い基本 external generated API レスポンスなど 対策: 例外的に機能横断的なものを管理するパッケージを⽤意
    
47. ドメイン特有ではあるが、ロジッ クは単純 宣⾔的なコードが多い 要素の定義が中⼼であり、実装関連のコードは⼊ らない 横断的機能のパッケージの特徴
    
48. パッケージ構成
    
49. 結論
    
50. 「レイヤー化」された パッケージ構成を
 適⽤した
    
51. 
    
52. ΤϯδχΞืूத ͓ؾܰʹ࿈བྷ͍ͩ͘͞ʂ