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