10年間で約15万行のコードを抱え、jQuery -> React + DDD -> React + Redux とアーキテクチャの変遷を辿ってきたChatworkを事例として、 組織フェーズの変化によって発生する課題と、それらをアーキテクチャの観点からどのように乗り越えるか紐解きたいと思います。
© Chatwork組織フェーズを見据えたWebフロントエンドのアーキテクチャと変遷フロントエンド開発部 澁谷 哲也2021年11月27日
View Slide
自己紹介2Chatwork株式会社澁谷 哲也 Tetsuya Shibutaniフロントエンド開発部 マネージャービジネスチャットツールを作っています@shibe_23
Chatworkの歴史と組織規模の変遷(登録ID数:各年12月末時点、2021年のみ9月末時点。従業員数: 各年10月末時点)登録ID数フロントエンドチームメンバー数従業員数+ DDD🔔2019/09/24東証マザーズ上場81名 87名109名154名247名33名4名 6名178.2万ID241.6万ID308.0万ID395.2万ID458.2万ID約2.3倍
Chatworkのフロントエンドの特徴について4Chatworkは歴史のあるプロダクト○ リリースから10年○ フロントエンド部分のコードベースで約15万行
Chatworkのフロントエンドの特徴について5例: メッセージが表示される、タイムライン上の未読ライン● ウィンドウがアクティブかどうか● 表示してから◯秒経過した● メッセージを送信したときは全て既読にする etc...クライアントサイドもビジネスロジックがてんこ盛り● あらゆる状態が1つのページで複雑に絡まり合っている○ メッセージ、ルーム、タスク、権限...● ルーティングで特定エンドポイントごとに区切ってリファクタリング、ができないページという概念がない
Chatworkのフロントエンドの特徴について6「安全に」「段階的に」リファクタリングをする仕組みが必要既に社会インフラに近い存在になっている● DAU 96.6万 (2021/9月末時点・最大)● 重篤な不具合 = ユーザーの業務が止まる
フロントエンドのアーキテクチャの変遷(1)7● 巨大なjQueryベースのSPA● Reactを導入し、ViewとModelの分離を試みた● 段階的にjQueryからReactへ置き換えるため、jQuery部分を明確に分離する必要がある○ DDDを元にしたDomain Modelの作成○ ACL(腐敗防止層)によりアーキテクチャを分離し、jQuery部分への依存を制御複雑化するjQueryからの脱却を目指し、ReactとDDDベースのモデリングを採用+ DDD
React + DDD:構成図8詳しくは下記blogをご覧くださいhttps://creators-note.chatwork.com/entry/2020/11/04/111353https://creators-note.chatwork.com/entry/2020/11/09/102425
React + DDD:サンプルコード9Render(propsの再生成)
フロントエンドのアーキテクチャの変遷(2)10● Propsを更新する仕組みが自前● 常に最上位コンポーネントからのレンダリングをするため、レンダリングコストが高い● mutableに状態を管理するため差分比較コストが高い技術面、組織面の課題からReduxを採用+ DDD技術的課題● 組織全体を拡大させていくフェーズに突入したが、実装に独自性が強くオンボーディングコストが高い組織的課題⇒ Redux導入で再レンダリングの範囲を狭める immutableにして差分比較コストを下げる⇒ デファクトスタンダードである状態管理ライブラリの採用により 最初から共通言語で会話できるように
Redux採用の効果(1): 再レンダリングの範囲を狭める11● react-reduxのuseSelectorを利用● Storeをsubscribeして、dispatchされる度に差分比較してくれる● Stateの差分検知・キャッシュ機構により、再レンダリングの範囲を狭めることができた
Redux採用の効果(2): immutableにして差分比較コストを下げる12● Redux Toolkitを活用○ immerによってimmutableな実装が可能● ClassベースのEntityをどうReduxに移行するか○ 値はcreateEntityAdapterを使ってStoreに格納○ メソッドはreducerなど種類ごとに分けて関数として定義
DDDベースのモデルとReduxの関係13● EntityやValue ObjectがStoreに再現しやすい● Application Serviceを見ればRedux化に必要なreducerやselectorが分かるDDDベースのモデルがあることでReduxの導入がスムーズだったクライアントサイドでもビジネスロジックの整理は重要● 戦術的な考え方を取り入れることはメリットがある● もちろんモデル分析をする姿勢も重要
Redux 処理フロー概要図14
Redux ディレクトリ構成(抜粋)15● Reduxを導入したコードは application 以下へ● feature単位でreducerやselector、Container Componentをまとめる● 各featureのactionをactions以下にまとめる
これから:機能別組織への挑戦とモジュラモノリスを意識した構成へ16● Reduxの導入を進めながら、feature単位での分割を行う● モジュラモノリス化を目指して、モノレポ構成への移行を段階的に進める組織全体で機能型組織への移行を検討● 採用計画が順調に進み、人数のスケールに関する課題感がより切実なものに● 職能型組織のため、機能開発はプロジェクトごとにメンバーをアサインする形式○ リポジトリのメンテナンスが職能型組織に紐づく○ 一つの機能開発で複数のチームに合意をとらなくてはならない○ 組織がスケールするほど調整コストがかかり、デリバリーをスケールさせづらい組織をスケールさせるために、モノリシックなSPAを分割していかなくてはいけない
まとめ17● 適切なモデリングへの探求● コードを疎結合に保ち、変更容易性を確保する● 新しいコードと古いコードの境界を設け、依存関係を制御する● 「アーキテクチャで解決すべき課題」は常に変わり続けるアーキテクチャの決定はプロダクトだけでなく、組織フェーズにも影響をうける● 過去のアーキテクチャもプロダクトや組織に貢献していれば負債ではない環境の変化は激しい。技術的負債を返却しながら新しい環境に適応する必要があるどんなアーキテクチャにするとしても、大事なことは変わらない
最後に18JSConf 2021アフターイベントとしてLTに収まらなかった話をしますhttps://chatwork.connpass.com/event/230070/12/1(水) 20:00 ~ 21:00フロントエンド・アーキテクチャの今までとこれからChatwork Tech Talk #6しぶたに たかせ
19働くをもっと楽しく、創造的に