Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトと一緒に成長できるMVCフレームワークの使い方 / Adjustable MVC Framework

プロダクトと一緒に成長できるMVCフレームワークの使い方 / Adjustable MVC Framework

〜 Ruby on Railsを例に 〜

B433dfef4ca935a7320df9fc96871aeb?s=128

Hiromichi NOMATA

January 03, 2022
Tweet

More Decks by Hiromichi NOMATA

Other Decks in Technology

Transcript

  1. プロダクトと⼀緒に成⻑できる MVCフレームワークの使い⽅ 〜 Ruby on Railsを例に 〜 @hiromichinomata

  2. MVCが得意なところ苦⼿なところ

  3. MVCフレームワークとは • Web開発でよく使われる設計の⼀つ • Model(M), View(V), Controller(C) • データベースの操作、表示、全体制御 •

    採⽤例: Ruby on Rails、Django(MVT)、 Laravel、 Blitz.js • 不採⽤例 • リクエストからレスポンスまで⼀つの関数 • Event Sourcing(Lagom)
  4. MVCが使われる理由 • ⾼い⽣産性(少なくとも初期では) • Y Combinatorで評価額が⼤きく上がっ た⾔語 https://charliereese.ca/article/top-50-y-combinator-tech-startups (ゲーム、ハードウェア、リプレイス除く) •

    スタートアップにおいて90%はRailsみ たいなことで実現できる
  5. MVC(RDBMS)が使われる理由 • MVCのMはRDBMS(MySQL, PostgreSQL)と密結合 • NoSQLのプロダクトトレンドからのズレ • Web広告の規制: DSPの優先度低下 •

    ソシャゲ ガチャ規制: 技術⼒ != ⼤量のアクセスを捌く • 機械学習ブーム: パーソナライズ(集計)がより重要に • 位置情報(ARグラス、⾃動運転)が重要になればNoSQL復活するかも?
  6. MVCフレームワークでなくても苦⼿なところ • Span of Controlと単⼀名前空間の限界 • ⼈とシステムは連動している(コンウェイの法則) • Span of

    control: 5-9⼈ • マネジャーが⾒れないならメンバーはもっと⾒れない => 名前空間は分けよう(Railsの機能としてある)
  7. MVCフレームワークが苦⼿なところ • ActiveRecord(ORM)はModel: Table = 1:1に特化 • ActiveRecord内で複数テーブルを⼀括操作するのは苦⼿ • 規模が⼩さいとMVC有利

    • Controller => Model <=> Table • 規模が⼤きいとドメインモデル(中間概念)優位 • Controller => Repository => Model <=> Table
  8. チーム分割と MVCフレームワークの モジュール化

  9. 分け⽅のルートはどこか • role: User/Company/Admin/API • シンプルだがmodel共通になりがち。認知負荷の減少が少ない • Read/Write: CQRS(Command Query

    Responsibility Segregation) • GraphQL: Query/Mutation. MVCフレームワークと相性悪い • domain: 似た機能でまとめる • 何度でも適⽤可能(Shopify)だが分割の位置を決めるのが⼤変
  10. 機能分割単位とデプロイ単位は独⽴ • モノリス: 素のRails. 同⼀名前空間に全て詰める • モジュラーモノリス: Shopify (Rails Engine)

    • ミニサービス: デプロイ単位が複数モジュール • マイクロサービス: デプロイ単位が1モジュール
  11. モノリスファースト • マイクロサービスの提唱者 「モノリスファースト」 • マイクロサービスのドメイン境界決定は熟考が必要 • マイクロサービスのトランザクションは難しい • モノリス

    => モジュラーモノリス => ミニサービス => マイクロサー ビス
  12. 地続き感のあるドメイン境界の決め⽅ • ⾛り切ってしまったチームは開発を⽌めてドメインを整理 => 開発を⽌めずActiveRecordパターンから地続きでドメインモデルに移⾏したい • ロールであたりをつける • User: /u/posts,

    Company: /c/info • BtoCの⽅がCtoCより有利 => CtoCでもロールで整理しておく • /creator/posts, /watcher/search • X: user_infos, O: creator_infos, watcher_infos
  13. 素のMVCからの切り出し⽅

  14. サービスの複雑性の縦軸と横軸 ػೳ" ೝূ ػೳ# ܾࡁ ػೳ$ 幅(機能分割で乗り切る) 深さ(切り出しで乗り切る)

  15. デプロイ単位を変えない切り出し⽅ 3FBE 8SJUF %FDPSBUPS4FSJBMJ[FS ୯Ұςʔϒϧ /" 7JFX.PEFM2VFSZ ෳ਺ςʔϒϧ /" 7BMJEBUPS

    /" ୯Ұςʔϒϧ 'PSN0CKFDU3FQPTJUPSZ ෳ਺ςʔϒϧ ෳ਺ςʔϒϧ 4FSWJDF $PODFSO  
  16. デプロイ単位を変える切り出し⽅ • 例えば • 新規事業に既存事業のユーザーが欲しい • 決済は共通なので複数サービスで共⽤したい • レスポンス時間が合計されるので多段が増えると体験悪い •

    Goなどが有利だがサイト全体CDNをかける(Fastly)などの技も
  17. 地続きで別サービスに切り出すには(没案) • Active Resourceの場合(あまり使われない) • サービス間通信がORMのAPIと同じまま使えれば地続き • Blackboxでなく密結合 • GraphQLとか?

  18. 案: 全てのサービスはREST APIとする慣例 • SomeAbcServiceの引数はプリミティブ型とする(gRPCを参考に) • SomeAbcService.run(user_id: 123) => POST

    /internal/some_abc_service {user_id: 123} • サービスにはActiveRecordのインスタンスは直接渡さない • 設定でendpointは⾃身に向けるか別サーバーに向けるか選べる • HTTPを経由するオーバーヘッドは⼗分⼩さいとする
  19. まとめ 開発を⽌めずにプロダクトと共にMVCフレームワークを成⻑させるには • 幅⽅向 • Span of Controlを超えるタイミングでドメインを元にモジュール分割の⾒直 し •

    最初からロールごとに設計を整理してあると分割しやすい • 深さ⽅向 • MVCフレームワークデフォルトのディレクトリ構造だけで戦おうとせず都度 適切な切り出しの仕組みを使⽤