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

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

6521324f6ab5266cdcde1dd05945a27b?s=128

Shinpei Maruyama

July 03, 2016
Tweet

Transcript

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

  2. 自己紹介 • しんぺい a.k.a. 猫型蓄音機 • Scala Ruby Perl Swift

    • 妻の夫で息子の父親
  3. 息子紹介

  4. 宣伝

  5. M V Whatever?

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

    M V V(iew)M(odel) • etc.
  7. FAQ:何が違うの?

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

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

  10. PDS? • separation between the presentation aspects of a program

    (the user interface) and the rest of the functionality IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM
  11. PDS? • その名の通り、プレゼンテーション とドメインの分離

  12. PDS • This principle is the most prominent part of

    Model View Controller (MVC) IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM
  13. PDS? • 「Domain?あっDDDでやったとこ ろだ!!!!」<=頻出する間違い です • DDDで言うDomainModelとPDSの 言うDomainの関係は、無関係とい う関係

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

  15. MVWのMのことです

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

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

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

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

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

    WebAPIならJSONとか
  22. Wもわかりやすい • iOSならViewController • androidならActivity • RailsならController • ViewをレンダリングしたりViewを 変更したり

    • 入力を受け取ったり
  23. PDSふたたび • separation between the presentation aspects of a program

    (the user interface) and the rest of the functionality
  24. Presentation = View + Whatever 入力を受け取る 見た目を作る

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

  26. PDSみたび • separation between the presentation aspects of a program

    (the user interface) and the rest of the functionality
  27. Domain = the rest プレゼンテーション 以外全部です

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

  30. アバンパート終了

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

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

  33. Active Record Pattern

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

    ソッドに書く
  35. ARパターン適用前

  36. ARパターン適用後

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

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

  39. None
  40. ActiveRecordPattern再訪 • Patterns of Enterprise Application Architecture で紹介されたパターンの うちのひとつ •

    テーブルとクラスが1:1 • 実践DDD says:「単なるCRUDアプリ ケーションならばRuby On Railsで十分 だろう」
  41. ARパターンだけで 全てが解決できると 思ってはいけない

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

  43. Transaction Script

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

  45. TS適用

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

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

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

  50. Layered Architecture

  51. Layered Architecture Presentation ApplicationService DomainModel Infrastructure • VとW • Pが叩く窓口

    • これ以外すべて • DBアクセスとか
  52. in DomainModel

  53. in DomainModel

  54. in Infrastructure

  55. in ApplicationService

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

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

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

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

  61. Aパート終了

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

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

  64. Bパート GUIで実践編

  65. 連打マシーンを作る • 連打された数が表示されるカウンター と連打用ボタンが置いてある • ボタンを押すとカウントが +1 さ れる •

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

    ターをupdateする
  67. 意外と複雑!

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

  69. in Domain

  70. in Domain

  71. in Domain

  72. in ApplicationService

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

  74. Presentation層

  75. ViewController

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

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

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

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

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

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

  82. CounterをObservableに

  83. VCでObserve

  84. 完成や!!!

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

  86. PDS! IUUQNBSUJOGPXMFSDPNCMJLJ1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM

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

  88. 感動のエンドロール

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

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

  92. CounterLabel

  93. VCも変更

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

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

    • 本質的にはタイマーイベントと一緒なの では?
  96. • PにActionProviderという層があっ てもいいかもしれない • タイマーイベントを発行する君 • サーバーからのpushを受け取ってイベン ト発行する君 • VCがこれらのイベントを監視して

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

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

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

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

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

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

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

    トライフォースの力とともに進もう