ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント

https://speakerdeck.com/noritakaikeda/ji-neng-de-ning-ji-nogai-nian-woyong-ite-fu-shu-roru-lei-si-noji-neng-woduo-kuhan-musisutemuno-hurontoendonokonponentowoshi-qie-nifen-ge-suru
のLT版です。

Transcript

1. ドメイン駆動で設計する、 機能的凝集された フロントエンドコンポーネント 2026/08/20 AI時代のドメイン駆動設計 LT会 IkedaNoritaka
2. はじめに 自己紹介 ・NoritakaIkeda ・X(Twitter): @omotidaisukijp ・フロントエンド寄りのフルスタック ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 2
3. はじめに フロントエンドのコンポーネント どんな粒度で分けていますか ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 3
4. はじめに どっちが読みやすい？ (複数ロールある、商品詳細ページの例 ) A B ロールごとに条件分岐 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント ロールごとに コンポーネント分割 4
5. はじめに どっちが読みやすい？ B 厳密な正解がある わけではありません ロールごとにコンポーネント分割 本発表では、 Bを 目指したいという話をし ます ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 5
6. はじめに 今日話すこと 複数ロール、類似の機能を多く含む複雑なシステムの設計に、機能的凝集で立ち向かおう - 競合優位性を生む事業領域は、システムが複雑になる フラグによる条件付きレンダリングを減らすことで、論理的凝集を回避する 意味的に違う塊は別コンポーネントにする 共通化できる塊は思っているより少ない 機能的凝集を行うことで、チームのベロシティ、プロダクト品質が向上した - 他のメンバーが書いたコード、自分が過去に書いたコードを読みやすい 機能中心的に考える際、 APIのスキーマの構造、デザイン、要件を総合的にすり合わせて、各所へ フィードバックできる。プロダクトが本来目指すべき姿になっていく ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 6
7. はじめに 競合優位性を生む事業領域は、システムが複雑になる - 中核の事業領域 - 競合他社との違うを生み出す業務活動 - 売り上げを左右するような、ビジネスノウハウや知的財産・最適化された業務内容など。 - 複雑なことは必然 - 複雑な課題に正面から取り組む企業が大きな事業価値を生み出す - できるだけ競争相手が簡単に真似できないようにする - 変更容易性が求められる - 競合他社が追いつけない理由として、企業は中核の業務領域を常に革新し、進化させる - ソフトウェア開発も、様々な実装を試し、改善し続ける双発的なものになる 参照: Vlad Khononov 著、増田亨・綿引琢磨 訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』オライリー・ジャパン、2024年 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 7
8. はじめに コンポーネント分割の観点の例 ドメイン・要件的な観点 - ロールごとの分割 機能ごとの意味的な分割 関連するデータを集約するための分割 UI的な観点 - UIを構成する部品単位での分割 UIライブラリのラッパーコンポーネント レイアウト的に再利用可能なコンポーネント その他の観点 - フォームプロバイダーなど、技術的に必要な分割 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 8
9. はじめに 本スライドでは、ドメインや要件の観点の 分割の話題にフォーカスしています ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 9
10. はじめに 目次 - - 凝集度とは : - 機能的凝集と論理的凝集 - なぜ機能的凝集を目指すべきなのか 実際のプロジェクトで出会った機能的凝集パターン : - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 10
11. 1. 凝集度とは なぜ機能的凝集を目指すのか 11
12. 1. 凝集度とは 凝集度とは モジュール（関数、クラス、パッケージなど）が単一の目的にどれだけ集中しているか、内部の要素（変数、関 数など）がどれだけ密接に関連しているかを表す指標 - 凝集度は高い、低いで表現される 凝集度の高いモジュールは、堅牢性、信頼性、再利用性、可読性などの点で好ましい 偶発的凝集 論理的凝集 時間的凝集 手順的凝集 通信的凝集 逐次的凝集 機能的凝集 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 低い = 避けたい 高い = 好ましい 12
13. 1. 凝集度とは 本スライドでは論理的凝集と機能的凝集に注目する 様々な凝集度の中でも、 UIやコンポーネント設計において頻出する、論理的凝集や機能的凝集に注目 - UI観点のコンポーネント設計では時間的凝集や手順的凝集など上記以外の他の凝集は生まれにくい 偶発的凝集 論理的凝集 時間的凝集 手順的凝集 通信的凝集 逐次的凝集 機能的凝集 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 低い = 避けたい 高い = 好ましい 13
14. 1. 凝集度とは 論理的凝集とは 論理的凝集：似たような処理をフラグや条件で切り替えて 1つにまとめている状態（避けたい） - コンポーネントに条件分岐が多く点在するようになり、可読性が落ち、保守のコストが増加する 共通化としてやりがち 商品詳細画面 ロールごとの 機能を追加 ロールごとに条件分岐 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 14
15. 1. 凝集度とは 機能的凝集とは 機能的凝集：モジュール全体が単一の明確な目的のために構成されている状態（理想的な形） - コンポーネントの責務が明確になりがち 共通化したい余地が残る 商品詳細画面 ロールごとの 機能を追加 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント ロールごとにコンポーネント分割 15
16. 1. 凝集度とは 機能的凝集で共通化したい時には 共通化をしたいなら、それぞれのロールで共通する部分を、意味ある単位で切り出すと良い 共通化 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 16
17. 1. 凝集度とは 機能的凝集と論理的凝集 機能的凝集は責務ごとにコンポーネントを分け、論理的凝集は条件分岐で責務を切り替える。 機能的凝集 論理的凝集 比べると、、 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 17
18. 1. 凝集度とは なぜ論理的凝集を避けるのか 条件分岐 がコードの中に点在 コードが大きくなるにつれて、 条件分岐が増え、コードの複雑さが増していく 人間が書く文章 (要件定義書など )でも、 細部に場合分けが多い文章は読みにくいはず 「似ているから共通化したい」「今は簡単な 分岐だけだ」と思ったとしても、将来的に さらに条件を追加したくなるような場合は多い ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 18
19. 1. 凝集度とは なぜ論理的凝集を避けるのか 条件分岐がコードの中に点在 🚩開発初期の判断（ありがちな思考） : 「購入者と出品者で商品詳細の UI、ほとんど同じだし、 ひとつの ProductDetailコンポーネントで共通化しよう」 「今は価格と在庫の表示を切り替えるだけだし、 role === 'buyer'の条件で分ければ十分」 🧨 時間が経ってから発生する現実 : 「購入者のモバイルの画面ではレビューを非表示にして」 「出品者の画面ではドラフト状態の時だけ公開ボタン出して」 「在庫がない商品は購入者にも出品者にも警告を出す。 ただしアドミンには出さない」 「管理者用にも同じコンポーネント使って、 IDと出品者情報表示し て」 「購入者がログインしてないときは購入ボタンを押せなくして」 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 19
20. 1. 凝集度とは なぜ機能的凝集を目指すのか ✨機能の修正や追加に耐えやすい - コードの修正が他の機能まで影響しにくい 今修正したい、関心があるコードのみを読むことができる 機能的凝集をしておけば、追加するコードも機能的凝集しやすくなる 🔧 要件とコードが一致しているか確認しやすい - 要件定義書は機能単位で書かれているはずなので対応づけて読みやすい 別の機能を開発しているメンバー、デザインエンジニアと意思疎通がとりやすい ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 20
21. 1. 凝集度とは 🙋確かに良さそう！機能的凝集をしていきます！ ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 21
22. 1. 凝集度とは 🤔 ここ、条件分岐を入れざるを得ない気がする 🤔 機能的凝集をしようとすると分割の粒度が変になるな ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 22
23. 2. 実際のプロジェクトで出会った機能的凝集パターン コンポーネント分割の落とし穴とケーススタディ 23
24. 2. 実際のプロジェクトで出会った機能的凝集パターン 登壇者の参加したプロジェクト背景 DXを推進したい分野の複雑な業務ドメイン - - 複数ロール / 管理者ロール - ロールによって異なる業務フロー・状態遷移がある - ロール間で相互作用がある操作がある - ロールごとに異なる操作権限・閲覧権限がある 多岐にわたる業務フロー 前提 - フロントエンドチームは 5~7名程度 要件定義やデザイン、 APIスキーマは別チームが策定 React + Vite + GraphQL(型付きAPIスキーマ ) 参考のADR: https://tech.route06.co.jp/entry/2023/08/08/115253 具体的なドメインは公開できないため、以後、 ECドメインを参考にサンプルコードを提示します ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 24
25. 2. 実際のプロジェクトで出会った機能的凝集パターン 実際のプロジェクトで出会った、状況別、機能的凝集パターン 私たちのプロジェクトでよく出会ったり、設計的にトレードオフが強かった部分にフォーカスして、事例を共有し ます。それぞれの状況ごとに、私たちが行った判断を共有します。 - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 25
26. 2. 実際のプロジェクトで出会った機能的凝集パターン 実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Case1: 新規作成画面と編集画面 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 26
27. 2. 実際のプロジェクトで出会った機能的凝集パターン Pattern1: ルーティングで分岐できる場合 ルーティングから機能ごとの分岐ができる場合、そのまま分岐すると、 コンポーネント側で条件分岐を持つ必要がなくなって嬉しい ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 27
28. Pattern1: ルーティングで分岐できる場合 Case1: 新規作成画面と編集画面 なんだか似てる ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 28
29. Pattern1: ルーティングで分岐できる場合 Case1: 新規作成画面と編集画面 以下のような違いがある タイトルが違う 初期値が入っている ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 文字と 押下した 時の関数 が違う 29
30. Pattern1: ルーティングで分岐できる場合 Case1: 新規作成画面と編集画面 スキーマが同じでいいなら、フォームコンポーネントは 統一できる タイトル、送信のための関数や defaultValuesは、 Page側で責務を持つ設計だとシンプルで保守性が高い ルーティングから ページコンポーネントを呼 び出す ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 30
31. 2. 実際のプロジェクトで出会った機能的凝集パターン 実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - - Case3: 通知機能 Pattern3: 共通化したいなという気持ちが湧き出てきた場合 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 31
32. 2. 実際のプロジェクトで出会った機能的凝集パターン Pattern2: 分岐がコンポーネント内から排除出来ない APIなどから取得したデータやその型を元に分岐しなければならない場合、 Pattarn1と違い、データ取得箇所から UI表示までのどこかに条件分岐が発生する → 論理的凝集せざるを得ない？ ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 32
33. Pattern2: 分岐がコンポーネント内から排除出来ない場合 Case4: 通知機能 通知はサイトを横断的にトリガーされるため、様々な UIデザインパターンが存在しやすい UI的に似ているが、以下の点で違いがある - 表示するラベルに入っているデータの種類・数 - 通知を押下して遷移する先の画面 想定する通知の型 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 33
34. Pattern2: 分岐がコンポーネント内から排除出来ない場合 Case4: 通知機能 定義されている APIのスキーマ型を ts-patternで 出し分けると機能的凝集になりやすい .exhaustive()を用いることで、型の抜け漏れを防げる 追加開発のタイミングでも、特定の通知が飛ばない ようなエラーを未然に防げる ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 34
35. 2. 実際のプロジェクトで出会った機能的凝集パターン 実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 35
36. 2. 実際のプロジェクトで出会った機能的凝集パターン Pattern3: 共通化したいなという気持ちが芽生えた時 共通化したいなと思う、エンジニア的な嗅覚・直感 - コードを局所的に見て、「ここの実装似ているかも？」「過去に似た実装をした記憶がある」「共通化した 先の幸せな未来が見える」 機能的な関連性を正しく評価したい - 要件、デザイン、 APIのスキーマの型からヒントを集め、総合的に判断する - 要件、デザイン、 APIのスキーマは、実装がない中、様々な仮定のなかで作成されているものなので、そ れらの辻褄をしっかり合わせる作業になる ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 36
37. Pattern3: 共通化したいなという気持ちが芽生えた時 そもそも分割するに値するか、以下の要素から判断する 分割したい箇所の実装量、実装の複雑さ - ループ処理、状態管理、条件分岐などが入ってくると分割する価値があるかもしれない 分割したい箇所が、 Figmaでグルーピングもしくはコンポーネント化されているか - 共通化したいからといって、意味的に一塊のものから無理に切り出していないか 分割したい箇所が、 APIのスキーマのオブジェクト型の塊と一致しているか - オブジェクト型でまとまっているものは一つの意味の塊として見出しやすい チーム内の (形式的/暗黙的な )合意に従う - コード規約 - 実際のコードの分割粒度 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 37
38. Pattern3: 共通化したいなという気持ちが芽生えた時 共通化できる時とはどんな時か (実装も、 Figma上も似通っている前提 ) 要件定義的にも同じと言えるか - 購入者視点の「購入履歴画面」と、管理者視点の「注文管理画面」だと、意味的に同じだと言いにくい - その中のに通った UIを共通化していいか十分に注意を払うべき APIのスキーマのオブジェクト型的に同じかどうか - Buyerオブジェクトの中の Userオブジェクトと、 SellerUserオブジェクトは同じだと言いにくい - 十分注意して共通化の判断をするか、 APIスキーマ側で Sellerオブジェクトの中の Userオブジェクトみたい な実装にできないか相談 ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 38
39. まとめ やってよかったこと チームのベロシティが安定した - 別のメンバーが担当していた機能のコードが読みやすく、誰でもどの機能の開発にもスムーズに入れる 状態 pjの進め方として、タスクを細かくし、早く自分のタスクが終わった人は作業量が多い機能に入っていく 形式をとっていたので、マッチした コードと要件の対応がわかりやすいため、オンボーディングしやすい リリース前の QAやテストなどでバグが報告された時、数ヶ月前に実装した自分のコードのキャッチアップ速度 が速くなる ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 39
40. まとめ 今日話すこと 複数ロール、類似の機能を多く含む複雑なシステムの設計に、機能的凝集で立ち向かおう - 競合優位性を生む事業領域は、システムが複雑になる フラグによる条件付きレンダリングを減らすことで、論理的凝集を回避する 意味的に違う塊は別コンポーネントにする 共通化できる塊は思っているより少ない 機能的凝集を行うことで、チームのベロシティ、プロダクト品質が向上した - 他のメンバーが書いたコード、自分が過去に書いたコードを読みやすい 機能中心的に考える際、 APIのスキーマの構造、デザイン、要件を総合的にすり合わせて、各所へ フィードバックできる。プロダクトが本来目指すべき姿になっていく ドメイン駆動で設計する、機能的凝集されたフロントエンドコンポーネント 40