$30 off During Our Annual Pro Sale. View Details »

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

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

Shinpei Maruyama

July 03, 2016
Tweet

More Decks by Shinpei Maruyama

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

  3. 息子紹介

    View Slide

  4. 宣伝

    View Slide

  5. M V Whatever?

    View Slide

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

    View Slide

  7. FAQ:何が違うの?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. MVWのMのことです

    View Slide

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

    View Slide

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

    View Slide

  18. ビジネスロジック
    とは一体(哲学)

    View Slide

  19. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  28. View Slide

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

    View Slide

  30. アバンパート終了

    View Slide

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

    View Slide

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

    View Slide

  33. Active
    Record
    Pattern

    View Slide

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

    View Slide

  35. ARパターン適用前

    View Slide

  36. ARパターン適用後

    View Slide

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

    View Slide

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

    View Slide

  39. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. Transaction
    Script

    View Slide

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

    View Slide

  45. TS適用

    View Slide

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

    View Slide

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

    View Slide

  48. View Slide

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

    View Slide

  50. Layered
    Architecture

    View Slide

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

    View Slide

  52. in DomainModel

    View Slide

  53. in DomainModel

    View Slide

  54. in Infrastructure

    View Slide

  55. in ApplicationService

    View Slide


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

    View Slide

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

    View Slide

  58. View Slide

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

    View Slide

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

    View Slide

  61. Aパート終了

    View Slide

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

    View Slide

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

    View Slide

  64. Bパート
    GUIで実践編

    View Slide

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

    View Slide

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

    View Slide

  67. 意外と複雑!

    View Slide

  68. まずはModelを
    考えてみる

    View Slide

  69. in Domain

    View Slide

  70. in Domain

    View Slide

  71. in Domain

    View Slide

  72. in ApplicationService

    View Slide

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

    View Slide

  74. Presentation層

    View Slide

  75. ViewController

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  81. Observerパターンで
    やったところだ!

    View Slide

  82. CounterをObservableに

    View Slide

  83. VCでObserve

    View Slide

  84. 完成や!!!

    View Slide


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

    View Slide

  86. PDS!
    IUUQNBSUJOGPXMFSDPNCMJLJ1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM

    View Slide

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

    View Slide

  88. 感動のエンドロール

    View Slide

  89. いきなり数字が
    < 飛ぶぞ!!!!
    これはバグだ!

    View Slide

  90. View Slide

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

    View Slide

  92. CounterLabel

    View Slide

  93. VCも変更

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  100. ここから先は
    君自身の目で
    たしかめよう!

    ▲▲

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide