Androidアプリにおけるソフトウェア設計の考え方

2018/3/12 Bonfire Android #3
https://yj-meetup.connpass.com/event/79749/

Transcript

1. Androidアプリにおけるソフトウェア設計の考え⽅ 2018/3/12 @yomuraya Bonfire Android #3
2. ⾃⼰紹介 • 村⼭ 庸平（むらやま ようへい) • ヤフー株式会社 • しんそつ2004（14年⽬） • 2011年ごろからAndroid • Yahoo! JAPANウィジェット • Yahoo! JAPANアプリ • Yahoo!カーナビ • Yahoo! MAP • 最近Arduinoをはじめました
3. はじめに • 設計のお話中⼼のため、実装の話は出てきません • あくまで考え⽅なので、お困りごとは解決出来ないかもしれません • OOD、DDDにピンと来る⽅は知ってる内容かもしれません • 時間の関係で説明しきれない箇所が出るかもしれません • 詳しくは懇談会のときにでも
4. アジェンダ • アーキテクチャのおさらい • アプリにおける設計の考え⽅ • 簡単な設計例
5. よく使われるアーキテクチャ
6. Model-View-Controller Model View Controller
7. Model-View-Controller • 古くからあるアーキテクチャ • ユーザーの⼊⼒はControllerからModelに通知される • データの変更はModelからViewに通知される • GUIに適応するとViewとControllerが密結合になりやすい
8. Model-View-ViewModel View ViewModel Model
9. Model-View-ViewModel • Microsoft Silverlightで採⽤されたアーキテクチャ • ViewとModelをViewModelでつなぐシンプルなしくみ • ユーザーの⼊出⼒はViewに集約されるため考えやすい • データバインディングと相性がよい • Modelを細分化するとViewModelが肥⼤化する
10. The Clean Architecture https://github.com/android10/Android-CleanArchitecture
11. The Clean Architecture • “ボブおじさん”ことロバート・C・マーチン⽒提唱 • UIやフレームワーク、DBなどが密結合にならないように層を分離する • より内部に⾏くほど他から影響を受けない実装になる • 外側に⾏くほど、よりシステムやUIに特化した実装になる
12. アプリ設計の考え⽅
13. それぞれのアーキテクチャの共通点 • View(UI)とModelを分離したい • Model＝ビジネスロジック • モデル≠データストア • Web時代とViewの定義が異なってきている • Web：主に表⽰のみ。⼊⼒はURLで別に来る • App：⼊⼒も出⼒も担当
14. アプリにおけるビジネスロジック • ビジネスロジック＝
 全ロジック ー (UIに依存したロジック ＋ プラットフォームに依存したロジッ ク) • ⾔い換えれば、UIにもプラットフォームにも依存しないロジック • プラットフォームはビジネスを実現する⼿段であってやりたいことではない • ライフサイクルが異なるロジックを混ぜるべきではない
15. ロジックのライフサイクル • UIに依存するロジック • ⾒た⽬の変更は何よりライフサイクルが早い • ユーザーが使いにくいとわかればすぐに変更される • プラットフォームに依存するロジック • Androidの場合、年に1〜2回新しいAPI Levelが追加される • iOSの場合、年に1回ごっそりプラットフォームが変わる
16. ここまでの設計 UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
17. ここまでの設計 • UIとプラットフォームを分けたが、ビジネスロジックが整理されていない • アーキテクチャを導⼊しただけでは、複雑なソフトウェアになりがち • ビジネスロジックをどう分けるかをしっかり議論しないと、アプリの設計 とはいえない
18. ビジネスロジックを整理する⽅法 • オブジェクト指向分析設計（OOAD） • ドメイン駆動設計（DDD）
19. オブジェクト指向分析設計（OOAD） • 作りたいアプリの中にあるすべての情報を概念モデルに落 とし込み、クラスとインタフェースで表現する • 設計時にはUMLが使われる事が多い（クラス図、シーケン ス図など） • クラス、インタフェースを設計するときはSOLID原則に従 う
20. （参考）SOLID原則 • 単⼀責任の原則（SRP） • 開放/閉鎖の原則（OCP） • リスコフの置換原則（LSP） • インタフェース分離の原則（ISP） • 依存性逆転の原則（DIP）
21. ドメイン駆動設計（DDD） • アプリで⾏いたいことを「ドメイン」と呼び、それをモデ ル化していく • チーム内で話されている⾔葉を共通⾔語（ユビキタス⾔ 語）として、それを設計に取り込む • アプリに出てくる「名詞」や「動詞」がそれぞれクラスや メソッドに対応するようになる • 極論を⾔えば、設計書を⾒ればアプリの実装がわかるよう になる
22. 具体的なビジネスロジックの整理
23. お題：ボタンを押したら画像を表⽰する Button Activity OkHttp ImageView ΫϦοΫΠϕϯτ URL byte[] Bitmap
24. 関⼼の分離 • ActivityはUIを管理するクラスであるので、ビジネスロジックを書くには 不適切 • ActivityはImageViewに渡すBitmapが欲しいのであって、byte[]が必要な のではない • URLもActivityが知っている必要はない • 関⼼を分けることで境界を作る
25. 画像取得クラスを作成 ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap
26. 仕様変更：⼀度取った画像はローカルに保存しておいて • Activityはローカルストレージがどんな仕組みなのか知るべきではない • 画像取得クラスは画像の取得が責務なので、ローカルストレージは関⼼事 から外れる • 単⼀責任の原則：変更の理由は⼀つでなければならない • ローカルストレージはプラットフォームの⼀部である • ライフサイクルが異なるロジックは分ける
27. 画像保存クラスを作成(1) ImageView Button Activity ը૾औಘ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ※ActivityʹϏδωεϩδοΫ͕࢒ͬͯ͠·͍ͬͯΔ
28. 画像保存クラスを作成(2) ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ϩʔΧϧ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap UI ϏδωεϩδοΫ ϓϥοτϑΥʔϜ
29. 仕様変更その2：プライバシーに配慮してストレージは暗号化して • ソフトウェア開発において、仕様変更は⽇常 • 適切に設計ができていれば、影響範囲は最⼩にできる
30. 暗号ストレージへの変更 ImageView Button Activity ը૾Ϟσϧ OkHttp URL byte[] Bitmap ΫϦοΫΠϕϯτ Bitmap ը૾อଘ ҉߸ ετϨʔδ Bitmap Bitmap ωοτϫʔΫ ը૾औಘ Bitmap Өڹൣғ͸͚ͩ͜͜
31. エンジニアの平穏は保たれた
32. まとめ • 名のあるアーキテクチャを採⽤するだけでは設計したとはいえない • UIとビジネスロジックを分けるのはもちろん、プラットフォームも分ける • オブジェクト指向はちゃんと理解しよう • クラスの関⼼・責務を考えよう • ドメイン駆動ができると幸せになれるかも？