あの日見た M V Whateverの Modelを僕たちはまだ知らない

by Shinpei Maruyama

Slide 1

Slide 1 text

by しんぺい a.k.a. 猫型蓄音機あの日見た M V Whateverの Modelを僕たちはまだ知らない

Slide 2

Slide 2 text

自己紹介 • しんぺい a.k.a. 猫型蓄音機 • Scala Ruby Perl Swift • 妻の夫で息子の父親

Slide 3

Slide 3 text

息子紹介

Slide 4

Slide 4 text

宣伝

Slide 5

Slide 5 text

M V Whatever？

Slide 6

Slide 6 text

MVW • M V C(ontroller) • M V P(resenter) • M V V(iew)M(odel) • etc.

Slide 7

Slide 7 text

FAQ：何が違うの？

Slide 8

Slide 8 text

どこが同じでどこが違うの？ • MVWは全て、Presentation Domain Separationの実現のためのパターン • 実現の仕方が細かく言うといろいろ違う

Slide 9

Slide 9 text

PDS? • http://martinfowler.com/bliki/ PresentationDomainSeparation. html

Slide 10

Slide 10 text

PDS? • separation between the presentation aspects of a program (the user interface) and the rest of the functionality IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM

Slide 11

Slide 11 text

PDS? • その名の通り、プレゼンテーションとドメインの分離

Slide 12

Slide 12 text

PDS • This principle is the most prominent part of Model View Controller (MVC) IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM

Slide 13

Slide 13 text

PDS? • 「Domain？あっDDDでやったところだ！！！！」<=頻出する間違いです • DDDで言うDomainModelとPDSの言うDomainの関係は、無関係という関係

Slide 14

Slide 14 text

じゃあPDSで言うところの Domainってなあに？

Slide 15

Slide 15 text

MVWのMのことです

Slide 16

Slide 16 text

じゃあMVWで言うところの Modelってなあに？

Slide 17

Slide 17 text

よくある説明 • Model：ビジネスロジック • View：見た目 • Whatever：ModelとViewをつなぐもの

Slide 18

Slide 18 text

ビジネスロジックとは一体（哲学）

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

わからないときはわかりやすいところから考えよう

Slide 21

Slide 21 text

Viewはわかりやすい • iOSならUIView • AndroidにもViewクラスがありますね • WebAppならばHTML(DOM)+CSS ですね • WebAPIならJSONとか

Slide 22

Slide 22 text

Wもわかりやすい • iOSならViewController • androidならActivity • RailsならController • ViewをレンダリングしたりViewを変更したり • 入力を受け取ったり

Slide 23

Slide 23 text

PDSふたたび • separation between the presentation aspects of a program (the user interface) and the rest of the functionality

Slide 24

Slide 24 text

Presentation = View + Whatever 入力を受け取る見た目を作る

Slide 25

Slide 25 text

では M = Domain の部分はなんなのか

Slide 26

Slide 26 text

PDSみたび • separation between the presentation aspects of a program (the user interface) and the rest of the functionality

Slide 27

Slide 27 text

Domain = the rest プレゼンテーション以外全部です

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

MVWは Modelの設計方針を何一つ語っていない！！！！ MVWは Modelの設計方針を何一つ語っていない！！！！

Slide 30

Slide 30 text

アバンパート終了

Slide 31

Slide 31 text

あの日見た M V Whateverの Modelを僕たちはまだ知らない

Slide 32

Slide 32 text

Modelのアーキテクチャ例 • ActiveRecordPattern • TransactionScript • LayeredArchitecture

Slide 33

Slide 33 text

Active Record Pattern

Slide 34

Slide 34 text

ActiveRecordPattern • テーブルとクラスが1:1 • rowとインスタンスが1:1 • テーブルに対する操作をクラスメソッドに書く • rowに対する操作をインスタンスメソッドに書く

Slide 35

Slide 35 text

ARパターン適用前

Slide 36

Slide 36 text

ARパターン適用後

Slide 37

Slide 37 text

• Rack経由せずにテストできるようになった！ • rake タスクとかからも呼べるよね〜

Slide 38

Slide 38 text

よくある課題 • 複数のテーブルにまたがるロジックどうするの？ • トランザクションどこで制御すんの？

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

ActiveRecordPattern再訪 • Patterns of Enterprise Application Architecture で紹介されたパターンのうちのひとつ • テーブルとクラスが1:1 • 実践DDD says:「単なるCRUDアプリケーションならばRuby On Railsで十分だろう」

Slide 41

Slide 41 text

ARパターンだけで全てが解決できると思ってはいけない

Slide 42

Slide 42 text

ちなみに • RoRのARはARパターンをベースにしたライブラリだけど、さらに拡張が加えられている • RoRではARベースで問題を解決しようとするアプローチもあるっぽいがうまく行ってるという話はあまり聞かない[要出典]

Slide 43

Slide 43 text

Transaction Script

Slide 44

Slide 44 text

TransactionScript • ユースケースと1:1のメソッド • ユースケースに対応する手続きをそのメソッドに書いていく • まさに「script:台本」

Slide 45

Slide 45 text

TS適用

Slide 46

Slide 46 text

• ARだけでは実現できなかった、複数の関心にまたがるユースケースを実現できた • トランザクションもばっちり

Slide 47

Slide 47 text

よくある課題 • コピペ地獄 • 1メソッドの長さが100000000行 • 1メソッド読み終えるのに5億年かかる

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

ちなみに • とはいえ、WebApplicationや WebAPIではトランザクションスクリプトで問題ないケースは結構あると思う

Slide 50

Slide 50 text

Layered Architecture

Slide 51

Slide 51 text

Layered Architecture Presentation ApplicationService DomainModel Infrastructure • VとW • Pが叩く窓口 • これ以外すべて • DBアクセスとか

Slide 52

Slide 52 text

in DomainModel

Slide 53

Slide 53 text

in DomainModel

Slide 54

Slide 54 text

in Infrastructure

Slide 55

Slide 55 text

in ApplicationService

Slide 56

Slide 56 text

• 一枚岩のスクリプトだったのが責務分散された • 複雑化しすぎたTransactionScript はテスタビリティが悪化する • テスタビリティを取り戻した • DomainはDBなしでテストできる

Slide 57

Slide 57 text

よくある課題 • 難しい • 「これどこに書けばいいの？」 • ちゃんとOOPで設計できないプログラマにとってはTSの手続き型のほうがわかりやすい。というかOOはやっぱり難しいですよ • ドメイン層、やっていくしかない

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

とはいえ • われわれはそもそも複雑な問題を解決するためにこのパターンにたどり着いた • たとえ難しくてもやっていく価値はある • OOPやDDDを頑張って学ぼう

Slide 60

Slide 60 text

FAQ • Q.これって要するにDDDのこと？ • A.惜しいです。 • LayeredArchitectureはDDDで触れられるパターンのうちのひとつ。DDDはLAのほかにもユビキタス言語とか境界付けられたコンテキストとかいろいろ含む

Slide 61

Slide 61 text

Aパート終了

Slide 62

Slide 62 text

アイキャッチあの日見た M V Whateverの Modelを僕たちはまだ知らない

Slide 63

Slide 63 text

アイキャッチあの日見た M V Whateverの Modelを僕たちはまだ知らない

Slide 64

Slide 64 text

Bパート GUIで実践編

Slide 65

Slide 65 text

連打マシーンを作る • 連打された数が表示されるカウンターと連打用ボタンが置いてある • ボタンを押すとカウントが +1 される • 自分だけじゃなくてネットワーク越しにみんなで連打しまくる

Slide 66

Slide 66 text

実装方針 • クライアントで連打数をバッファリングして一定時間おきにサーバーにflush • ただし、タップしたらすぐに見た目上のカウンターの数が増えるようにする • サーバーから定期的に「現在の総連打数」が送られてくるので、そのときはカウンターをupdateする

Slide 67

Slide 67 text

意外と複雑！

Slide 68

Slide 68 text

まずはModelを考えてみる

Slide 69

Slide 69 text

in Domain

Slide 70

Slide 70 text

in Domain

Slide 71

Slide 71 text

in Domain

Slide 72

Slide 72 text

in ApplicationService

Slide 73

Slide 73 text

アプリケーションの挙動はモデリングできた

Slide 74

Slide 74 text

Presentation層

Slide 75

Slide 75 text

ViewController

Slide 76

Slide 76 text

Presentation層からイベントを受けて Applicationを invokeするところまでできた

Slide 77

Slide 77 text

しかしこのままでは Viewが描き変わらない

Slide 78

Slide 78 text

Counterの状態が変わったら UILabelを書き換えたい

Slide 79

Slide 79 text

Xの状態が変わったら Yを書き換えたい

Slide 80

Slide 80 text

Xの状態が変わったら Yを書き換えたい

Slide 81

Slide 81 text

Observerパターンでやったところだ！

Slide 82

Slide 82 text

CounterをObservableに

Slide 83

Slide 83 text

VCでObserve

Slide 84

Slide 84 text

完成や！！！

Slide 85

Slide 85 text

• ドメインは一切プレゼンテーションに依存していない • テスタブルだし、CocoaTouchに依存してないから「わかりやすい」

Slide 86

Slide 86 text

PDS！ IUUQNBSUJOGPXMFSDPNCMJLJ1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM

Slide 87

Slide 87 text

yudetamago, STAR ZERO and YOU 感動のエンドロール

Slide 88

Slide 88 text

感動のエンドロール

Slide 89

Slide 89 text

いきなり数字が＜飛ぶぞ！！！！これはバグだ！

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

UIの問題なので Presentationの領域で解決しましょう

Slide 92

Slide 92 text

CounterLabel

Slide 93

Slide 93 text

VCも変更

Slide 94

Slide 94 text

• UIの変更がPのみでできた • Dは一切いじってない

Slide 95

Slide 95 text

そして設計沼へ…… • 今回ServerからのpushをハンドルしてくれるくんをModelに置いたけど、本当にこれでいいのか？ • Serverからのpush = アプリケーションへの入力では？ • 本質的にはタイマーイベントと一緒なのでは？

Slide 96

Slide 96 text

• PにActionProviderという層があってもいいかもしれない • タイマーイベントを発行する君 • サーバーからのpushを受け取ってイベント発行する君 • VCがこれらのイベントを監視して ApplicationServiceをinvokeするそして設計沼へ……

Slide 97

Slide 97 text

• このObserverパターン素朴すぎる • Observerパターンはオブジェクトの mutationが前提 • immutableな設計と相性悪い • API呼び出しはInfrastructureに置いてDIするべきではそして設計沼へ……

Slide 98

Slide 98 text

• RepositoryとQueryの相性めっちゃわるい • ARにはあまりなかったRDBとOOのインピーダンスミスマッチがここにきて問題にそして設計沼へ……

Slide 99

Slide 99 text

• Fluxアーキテクチャとの統合…？ • CQRS…？ • EventSourcing…？そして設計沼へ……

Slide 100

Slide 100 text

ここから先は君自身の目でたしかめよう！ ▲ ▲▲

Slide 101

Slide 101 text

まとめ • PDSを心がけよう • MVWはプレゼンテーション層の作り方のパターン • Mの設計はまた別にちゃんと考える必要あり • トライフォースの力とともに進もう

Slide 102

Slide 102 text

宣伝 • 株式会社リラクでは、一緒に最高の設計を追求したいプログラマを募集しています • 声かけてください！