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 Framework
Search
Hiromichi NOMATA
January 03, 2022
Technology
1
330
プロダクトと一緒に成長できる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
510
エボルタNEOくん三輪車で学ぶ動くペーパクラフトとバルーン / Evolta NEO Three Wheeled Cycle
hiromichinomata
1
330
ガンダムとザクの構造比較から見る動くガンダムを手に入れるために必要なこと / Gundam vs Zaku
hiromichinomata
1
320
投下資本に比例して成長できる開発組織体制について / How To Create Scalable Development Team
hiromichinomata
1
380
絵文字扇子の作り方 / How to create Emoji Sensu
hiromichinomata
1
380
Ruby 2.7クイズ / Ruby 2.7 Quiz
hiromichinomata
1
250
クララと学ぶbash / Learn bash with Clara
hiromichinomata
1
27
クララと学ぶプログラミング / Learn Programming with Clara
hiromichinomata
1
75
Other Decks in Technology
See All in Technology
データベース02: データベースの概念
trycycle
0
160
いつか使うかも貯金してたらめちゃめちゃ機能が増えてた話
riyaamemiya
0
290
20240418_Google ColabにLLMが搭載されたようなのでPython x データ分析の勉強方法を考えてみる
doradora09
0
140
元インフラエンジニアに成る / Human Resources to Human Relations
bobtani
4
930
KubeCon EU 2024 Recap “Kubernetes Policy Time Machine: Where to Next?”
ryysud
0
220
Terraformあれやこれ/terraform-this-and-that
emiki
8
1.4k
チームでロジカルシンキングに改めて向き合っている話 〜学習環境と実践⽅法〜
sansantech
PRO
3
2.6k
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
320
よく聞くけど使ったことないソフトウェアNo.1 KafkaとSnowflake
foursue
4
360
web-application-security
matsuihidetoshi
0
170
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
240
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
Featured
See All Featured
In The Pink: A Labor of Love
frogandcode
138
21k
How to train your dragon (web standard)
notwaldorf
73
5.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
78
43k
The Language of Interfaces
destraynor
151
23k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Teambox: Starting and Learning
jrom
128
8.4k
The Invisible Side of Design
smashingmag
294
49k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Rebuilding a faster, lazier Slack
samanthasiow
73
8.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
320
23k
Building Effective Engineering Teams - LeadDev
addyosmani
28
1.8k
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フレームワークデフォルトのディレクトリ構造だけで戦おうとせず都度 適切な切り出しの仕組みを使⽤