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
プロダクトと一緒に成長できるMVCフレームワークの使い方 / Adjustable MVC F...
Search
Hiromichi NOMATA
January 03, 2022
Technology
1
450
プロダクトと一緒に成長できるMVCフレームワークの使い方 / Adjustable MVC Framework
〜 Ruby on Railsを例に 〜
Hiromichi NOMATA
January 03, 2022
Tweet
Share
More Decks by Hiromichi NOMATA
See All by Hiromichi NOMATA
急にDX言い出した理由と真にDXを実現するために必要なこと / DX Explained
hiromichinomata
1
700
エボルタNEOくん三輪車で学ぶ動くペーパクラフトとバルーン / Evolta NEO Three Wheeled Cycle
hiromichinomata
1
640
ガンダムとザクの構造比較から見る動くガンダムを手に入れるために必要なこと / Gundam vs Zaku
hiromichinomata
1
630
投下資本に比例して成長できる開発組織体制について / How To Create Scalable Development Team
hiromichinomata
1
490
絵文字扇子の作り方 / How to create Emoji Sensu
hiromichinomata
1
630
Ruby 2.7クイズ / Ruby 2.7 Quiz
hiromichinomata
1
400
クララと学ぶbash / Learn bash with Clara
hiromichinomata
2
44
クララと学ぶプログラミング / Learn Programming with Clara
hiromichinomata
1
130
Other Decks in Technology
See All in Technology
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
210
[MIRU25] NaiLIA: Multimodal Retrieval of Nail Designs Based on Dense Intent Descriptions
keio_smilab
PRO
1
160
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
160
【CEDEC2025】大規模言語モデルを活用したゲーム内会話パートのスクリプト作成支援への取り組み
cygames
PRO
1
520
ユーザー理解の爆速化とPdMの価値
kakehashi
PRO
1
110
TypeScript 上達の道
ysknsid25
23
4.9k
SAE J1939シミュレーション環境構築
daikiokazaki
1
200
東京海上日動におけるセキュアな開発プロセスの取り組み
miyabit
0
210
AI コードレビューが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった
mutsumix
0
110
Microsoft Learn MCP/Fabric データエージェント/Fabric MCP/Copilot Studio-簡単・便利なAIエージェント作ってみた -"Building Simple and Powerful AI Agents with Microsoft Learn MCP, Fabric Data Agent, Fabric MCP, and Copilot Studio"-
reireireijinjin6
1
190
LLM開発を支えるエヌビディアの生成AIエコシステム
acceleratedmu3n
0
350
Wasmで社内ツールを作って配布しよう
askua
0
160
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
Designing for Performance
lara
610
69k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Visualization
eitanlees
146
16k
The Language of Interfaces
destraynor
158
25k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Side Projects
sachag
455
43k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Transcript
プロダクトと⼀緒に成⻑できる MVCフレームワークの使い⽅ 〜 Ruby on Railsを例に 〜 @hiromichinomata
MVCが得意なところ苦⼿なところ
MVCフレームワークとは • Web開発でよく使われる設計の⼀つ • Model(M), View(V), Controller(C) • データベースの操作、表示、全体制御 •
採⽤例: Ruby on Rails、Django(MVT)、 Laravel、 Blitz.js • 不採⽤例 • リクエストからレスポンスまで⼀つの関数 • Event Sourcing(Lagom)
MVCが使われる理由 • ⾼い⽣産性(少なくとも初期では) • Y Combinatorで評価額が⼤きく上がっ た⾔語 https://charliereese.ca/article/top-50-y-combinator-tech-startups (ゲーム、ハードウェア、リプレイス除く) •
スタートアップにおいて90%はRailsみ たいなことで実現できる
MVC(RDBMS)が使われる理由 • MVCのMはRDBMS(MySQL, PostgreSQL)と密結合 • NoSQLのプロダクトトレンドからのズレ • Web広告の規制: DSPの優先度低下 •
ソシャゲ ガチャ規制: 技術⼒ != ⼤量のアクセスを捌く • 機械学習ブーム: パーソナライズ(集計)がより重要に • 位置情報(ARグラス、⾃動運転)が重要になればNoSQL復活するかも?
MVCフレームワークでなくても苦⼿なところ • Span of Controlと単⼀名前空間の限界 • ⼈とシステムは連動している(コンウェイの法則) • Span of
control: 5-9⼈ • マネジャーが⾒れないならメンバーはもっと⾒れない => 名前空間は分けよう(Railsの機能としてある)
MVCフレームワークが苦⼿なところ • ActiveRecord(ORM)はModel: Table = 1:1に特化 • ActiveRecord内で複数テーブルを⼀括操作するのは苦⼿ • 規模が⼩さいとMVC有利
• Controller => Model <=> Table • 規模が⼤きいとドメインモデル(中間概念)優位 • Controller => Repository => Model <=> Table
チーム分割と MVCフレームワークの モジュール化
分け⽅のルートはどこか • role: User/Company/Admin/API • シンプルだがmodel共通になりがち。認知負荷の減少が少ない • Read/Write: CQRS(Command Query
Responsibility Segregation) • GraphQL: Query/Mutation. MVCフレームワークと相性悪い • domain: 似た機能でまとめる • 何度でも適⽤可能(Shopify)だが分割の位置を決めるのが⼤変
機能分割単位とデプロイ単位は独⽴ • モノリス: 素のRails. 同⼀名前空間に全て詰める • モジュラーモノリス: Shopify (Rails Engine)
• ミニサービス: デプロイ単位が複数モジュール • マイクロサービス: デプロイ単位が1モジュール
モノリスファースト • マイクロサービスの提唱者 「モノリスファースト」 • マイクロサービスのドメイン境界決定は熟考が必要 • マイクロサービスのトランザクションは難しい • モノリス
=> モジュラーモノリス => ミニサービス => マイクロサー ビス
地続き感のあるドメイン境界の決め⽅ • ⾛り切ってしまったチームは開発を⽌めてドメインを整理 => 開発を⽌めずActiveRecordパターンから地続きでドメインモデルに移⾏したい • ロールであたりをつける • User: /u/posts,
Company: /c/info • BtoCの⽅がCtoCより有利 => CtoCでもロールで整理しておく • /creator/posts, /watcher/search • X: user_infos, O: creator_infos, watcher_infos
素のMVCからの切り出し⽅
サービスの複雑性の縦軸と横軸 ػೳ" ೝূ ػೳ# ܾࡁ ػೳ$ 幅(機能分割で乗り切る) 深さ(切り出しで乗り切る)
デプロイ単位を変えない切り出し⽅ 3FBE 8SJUF %FDPSBUPS4FSJBMJ[FS ୯Ұςʔϒϧ /" 7JFX.PEFM2VFSZ ෳςʔϒϧ /" 7BMJEBUPS
/" ୯Ұςʔϒϧ 'PSN0CKFDU3FQPTJUPSZ ෳςʔϒϧ ෳςʔϒϧ 4FSWJDF $PODFSO
デプロイ単位を変える切り出し⽅ • 例えば • 新規事業に既存事業のユーザーが欲しい • 決済は共通なので複数サービスで共⽤したい • レスポンス時間が合計されるので多段が増えると体験悪い •
Goなどが有利だがサイト全体CDNをかける(Fastly)などの技も
地続きで別サービスに切り出すには(没案) • Active Resourceの場合(あまり使われない) • サービス間通信がORMのAPIと同じまま使えれば地続き • Blackboxでなく密結合 • GraphQLとか?
案: 全てのサービスはREST APIとする慣例 • SomeAbcServiceの引数はプリミティブ型とする(gRPCを参考に) • SomeAbcService.run(user_id: 123) => POST
/internal/some_abc_service {user_id: 123} • サービスにはActiveRecordのインスタンスは直接渡さない • 設定でendpointは⾃身に向けるか別サーバーに向けるか選べる • HTTPを経由するオーバーヘッドは⼗分⼩さいとする
まとめ 開発を⽌めずにプロダクトと共にMVCフレームワークを成⻑させるには • 幅⽅向 • Span of Controlを超えるタイミングでドメインを元にモジュール分割の⾒直 し •
最初からロールごとに設計を整理してあると分割しやすい • 深さ⽅向 • MVCフレームワークデフォルトのディレクトリ構造だけで戦おうとせず都度 適切な切り出しの仕組みを使⽤