Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
あの日見た M V Whateverの Modelを僕たちは まだ知らない
Search
Shinpei Maruyama
July 03, 2016
Programming
20
6.8k
あの日見た M V Whateverの Modelを僕たちは まだ知らない
Shinpei Maruyama
July 03, 2016
Tweet
Share
More Decks by Shinpei Maruyama
See All by Shinpei Maruyama
過去や未来を扱うのは難しい? 過去と未来に立ち向かうための勘所
shinpeim
3
3.8k
設計ナイト2022 トランザクションスクリプト
shinpeim
12
3.5k
Ruby (off|with) the Rails
shinpeim
20
5.1k
綱渡りバッチ脱出大作戦
shinpeim
3
3.6k
Building native apps with scala.js
shinpeim
2
1.3k
今あえてDRY原則に向き合う
shinpeim
51
560k
Nekogata Drum Sequencer written in Scala.js
shinpeim
2
3.9k
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
shinpeim
36
15k
Using Scala.js with the JavaScript ecosystems
shinpeim
0
2.3k
Other Decks in Programming
See All in Programming
REST API設計の実践 – ベストプラクティスとその落とし穴
kentaroutakeda
2
310
primeNumberでのRBS導入の現在 && RBS::Traceでinline RBSを拡充してみた
mnmandahalf
0
250
がんばりすぎないコーディングルール運用術
tsukakei
1
180
事業KPIを基に価値の解像度を上げる
nealle
0
200
鯛変だったRubyKaigi 2025 ── それでも楽しかった!
pndcat
0
130
AIエージェントによるテストフレームワーク Arbigent
takahirom
0
260
RubyKaigi Hack Space in Tokyo & 函館最速 "予習" 会 / RubyKaigi Hack Space in Tokyo & The Fastest Briefing of RubyKaigi 2026 in Hakodate
moznion
1
120
インターフェース設計のコツとツボ
togishima
2
480
TypeScript製IaCツールのAWS CDKが様々な言語で実装できる理由 ~他言語変換の仕組み~ / cdk-language-transformation
gotok365
7
370
少数精鋭エンジニアがフルスタック力を磨く理由 -そしてAI時代へ-
rebase_engineering
0
130
バリデーションライブラリ徹底比較
nayuta999999
1
420
衛星の軌道をWeb地図上に表示する
sankichi92
0
250
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
Automating Front-end Workflow
addyosmani
1370
200k
The World Runs on Bad Software
bkeepers
PRO
68
11k
Fireside Chat
paigeccino
37
3.5k
Become a Pro
speakerdeck
PRO
28
5.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Building Adaptive Systems
keathley
41
2.6k
Building Applications with DynamoDB
mza
95
6.4k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Transcript
by しんぺい a.k.a. 猫型蓄音機 あの日見た M V Whateverの Modelを僕たちは まだ知らない
自己紹介 • しんぺい a.k.a. 猫型蓄音機 • Scala Ruby Perl Swift
• 妻の夫で息子の父親
息子紹介
宣伝
M V Whatever?
MVW • M V C(ontroller) • M V P(resenter) •
M V V(iew)M(odel) • etc.
FAQ:何が違うの?
どこが同じでどこが違うの? • MVWは全て、Presentation Domain Separationの実現のため のパターン • 実現の仕方が細かく言うといろいろ 違う
PDS? • http://martinfowler.com/bliki/ PresentationDomainSeparation. html
PDS? • separation between the presentation aspects of a program
(the user interface) and the rest of the functionality IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM
PDS? • その名の通り、プレゼンテーション とドメインの分離
PDS • This principle is the most prominent part of
Model View Controller (MVC) IUUQNBSUJOGPXMFSDPNCMJLJ 1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM
PDS? • 「Domain?あっDDDでやったとこ ろだ!!!!」<=頻出する間違い です • DDDで言うDomainModelとPDSの 言うDomainの関係は、無関係とい う関係
じゃあPDSで 言うところの Domainって なあに?
MVWのMのことです
じゃあMVWで 言うところの Modelって なあに?
よくある説明 • Model:ビジネスロジック • View:見た目 • Whatever:ModelとViewをつなぐ もの
ビジネスロジック とは一体(哲学)
None
わからないときは わかりやすい ところから考えよう
Viewはわかりやすい • iOSならUIView • AndroidにもViewクラスがありま すね • WebAppならばHTML(DOM)+CSS ですね •
WebAPIならJSONとか
Wもわかりやすい • iOSならViewController • androidならActivity • RailsならController • ViewをレンダリングしたりViewを 変更したり
• 入力を受け取ったり
PDSふたたび • separation between the presentation aspects of a program
(the user interface) and the rest of the functionality
Presentation = View + Whatever 入力を受け取る 見た目を作る
では M = Domain の部分はなんなのか
PDSみたび • separation between the presentation aspects of a program
(the user interface) and the rest of the functionality
Domain = the rest プレゼンテーション 以外全部です
None
MVWは Modelの設計方針を 何一つ語っていな い!!!! MVWは Modelの設計方針を 何一つ語っていな い!!!!
アバンパート終了
あの日見た M V Whateverの Modelを僕たちは まだ知らない
Modelのアーキテクチャ例 • ActiveRecordPattern • TransactionScript • LayeredArchitecture
Active Record Pattern
ActiveRecordPattern • テーブルとクラスが1:1 • rowとインスタンスが1:1 • テーブルに対する操作をクラスメソッ ドに書く • rowに対する操作をインスタンスメ
ソッドに書く
ARパターン適用前
ARパターン適用後
• Rack経由せずにテストできるよう になった! • rake タスクとかからも呼べるよ ね〜
よくある課題 • 複数のテーブルにまたがるロジック どうするの? • トランザクションどこで制御すんの?
None
ActiveRecordPattern再訪 • Patterns of Enterprise Application Architecture で紹介されたパターンの うちのひとつ •
テーブルとクラスが1:1 • 実践DDD says:「単なるCRUDアプリ ケーションならばRuby On Railsで十分 だろう」
ARパターンだけで 全てが解決できると 思ってはいけない
ちなみに • RoRのARはARパターンをベースにした ライブラリだけど、さらに拡張が加えら れている • RoRではARベースで問題を解決しようと するアプローチもあるっぽいがうまく行っ てるという話はあまり聞かない[要出典]
Transaction Script
TransactionScript • ユースケースと1:1のメソッド • ユースケースに対応する手続きをそ のメソッドに書いていく • まさに「script:台本」
TS適用
• ARだけでは実現できなかった、複 数の関心にまたがるユースケースを 実現できた • トランザクションもばっちり
よくある課題 • コピペ地獄 • 1メソッドの長さが100000000行 • 1メソッド読み終えるのに5億年か かる
None
ちなみに • とはいえ、WebApplicationや WebAPIではトランザクションスク リプトで問題ないケースは結構ある と思う
Layered Architecture
Layered Architecture Presentation ApplicationService DomainModel Infrastructure • VとW • Pが叩く窓口
• これ以外すべて • DBアクセスとか
in DomainModel
in DomainModel
in Infrastructure
in ApplicationService
• 一枚岩のスクリプトだったのが責務 分散された • 複雑化しすぎたTransactionScript はテスタビリティが悪化する • テスタビリティを取り戻した • DomainはDBなしでテストできる
よくある課題 • 難しい • 「これどこに書けばいいの?」 • ちゃんとOOPで設計できないプログラマ にとってはTSの手続き型のほうがわかり やすい。というかOOはやっぱり難しい ですよ
• ドメイン層、やっていくしかない
None
とはいえ • われわれはそもそも複雑な問題を解 決するためにこのパターンにたどり 着いた • たとえ難しくてもやっていく価値は ある • OOPやDDDを頑張って学ぼう
FAQ • Q.これって要するにDDDのこと? • A.惜しいです。 • LayeredArchitectureはDDDで触れられ るパターンのうちのひとつ。DDDはLAの ほかにもユビキタス言語とか境界付けら れたコンテキストとかいろいろ含む
Aパート終了
アイキャッチ あの日見た M V Whateverの Modelを僕たちは まだ知らない
アイキャッチ あの日見た M V Whateverの Modelを僕たちは まだ知らない
Bパート GUIで実践編
連打マシーンを作る • 連打された数が表示されるカウンター と連打用ボタンが置いてある • ボタンを押すとカウントが +1 さ れる •
自分だけじゃなくてネットワーク越 しにみんなで連打しまくる
実装方針 • クライアントで連打数をバッファリング して一定時間おきにサーバーにflush • ただし、タップしたらすぐに見た目上の カウンターの数が増えるようにする • サーバーから定期的に「現在の総連打数」 が送られてくるので、そのときはカウン
ターをupdateする
意外と複雑!
まずはModelを 考えてみる
in Domain
in Domain
in Domain
in ApplicationService
アプリケーションの 挙動はモデリング できた
Presentation層
ViewController
Presentation層から イベントを受けて Applicationを invokeするところ までできた
しかし このままでは Viewが 描き変わらない
Counterの状態が 変わったら UILabelを 書き換えたい
Xの状態が 変わったら Yを 書き換えたい
Xの状態が 変わったら Yを 書き換えたい
Observerパターンで やったところだ!
CounterをObservableに
VCでObserve
完成や!!!
• ドメインは一切プレゼンテーション に依存していない • テスタブルだし、CocoaTouchに依 存してないから「わかりやすい」
PDS! IUUQNBSUJOGPXMFSDPNCMJLJ1SFTFOUBUJPO%PNBJO4FQBSBUJPOIUNM
yudetamago, STAR ZERO and YOU 感動のエンドロール
感動のエンドロール
いきなり数字が < 飛ぶぞ!!!! これはバグだ!
None
UIの問題なので Presentationの 領域で 解決しましょう
CounterLabel
VCも変更
• UIの変更がPのみでできた • Dは一切いじってない
そして設計沼へ…… • 今回Serverからのpushをハンドルして くれるくんをModelに置いたけど、本当 にこれでいいのか? • Serverからのpush = アプリケーション への入力では?
• 本質的にはタイマーイベントと一緒なの では?
• PにActionProviderという層があっ てもいいかもしれない • タイマーイベントを発行する君 • サーバーからのpushを受け取ってイベン ト発行する君 • VCがこれらのイベントを監視して
ApplicationServiceをinvokeする そして設計沼へ……
• このObserverパターン素朴すぎる • Observerパターンはオブジェクトの mutationが前提 • immutableな設計と相性悪い • API呼び出しはInfrastructureに置 いてDIするべきでは
そして設計沼へ……
• RepositoryとQueryの相性めっ ちゃわるい • ARにはあまりなかったRDBとOOの インピーダンスミスマッチがここに きて問題に そして設計沼へ……
• Fluxアーキテクチャとの統合…? • CQRS…? • EventSourcing…? そして設計沼へ……
ここから先は 君自身の目で たしかめよう! ▲ ▲▲
まとめ • PDSを心がけよう • MVWはプレゼンテーション層の作 り方のパターン • Mの設計はまた別にちゃんと考える 必要あり •
トライフォースの力とともに進もう
宣伝 • 株式会社リラクでは、一緒に最高の 設計を追求したいプログラマを募集 しています • 声かけてください!
まとめ • PDSを心がけよう • MVWはプレゼンテーション層の作 り方のパターン • Mの設計はまた別にちゃんと考える 必要あり •
トライフォースの力とともに進もう