Atomic Design から bulletproof-react へ – 構成リアーキテクト –

Transcript

1. © DMM © DMM CONFIDENTIAL Atomic Design から bulletproof-react へ – 構成リアーキテクト – 配信画面編
2. © DMM 自己紹介
 2 2 入社：2024年2月中途入社
 
 業務：ライブ配信&視聴画面の
 フロントエンド開発
 
 趣味：サウナ / 旅行
 坂本 悠
 ライブコミュニケーション開発部/3.0Bグループ
 CREチーム

3. © DMM 話すこと
 3 3 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ

4. © DMM 話すこと
 4 4 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 ※まだ開発途中です。構成や実装は変わる可能性があります。
 

5. © DMM 現在の問題点 
 
 ・アプリケーション数の多さ
 
 ・機能・仕様の複雑化
 
 ・コンポーネントの膨張と乱立
 
 
 課題と背景
 5 5
6. © DMM 課題と背景
 6 6 アプリケーション数の多さ 
 
 ・配信アプリや視聴アプリなど10個以上存在
 
 ・共通基盤が少なく、個別対応が積み重なりメンテナンス性が低下
 
 
 
 
 
 

7. © DMM 課題と背景
 7 機能・仕様の複雑化 
 
 ・1画面で100以上の機能が混在
 
 ・単体機能よりも複数機能が絡むケースの方が多い
 
 ・デバイスやサービス差異によって表示や挙動が異なる
 
 ・複雑機能や複数アプリにまたがると、Atomic Designでは 
 　コードが肥大化
 7
8. © DMM 課題と背景
 8 8 コンポーネントの膨張と乱立 
 
 ・主要4つの配信アプリだけで300コンポーネント超
 
 ・同じような役割のコンポーネントが各アプリに散在
 
 ・共通化されず、再利用性が低い状態
 
 

9. © DMM 課題と背景
 9 9 開発前の各アプリケーションのディレクトリ構成 
 
 
 ✖4

10. © DMM 課題と背景
 10 10 チームで目指すアーキテクチャ像 
 
 ・保守コストをなるべく減らす構成としたい
 
 ・今後の保守で技術負債を極力発生させない

11. © DMM 話すこと
 11 11 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 

12. © DMM コンポーネント構成選定
 12 12 コンポーネント構成候補 
 
 　FSD (Feature-Sliced Design)
 　　・機能ごとにレイヤーを分割する設計手法
 　　・厳格なルールでスライス内の構造を維持しやすく、再利用性が高い
 
 　Bulletproof React
 　　・機能単位のフォルダ構造で管理する設計手法
 　　・学習コストが低く理解しやすいが、細かいレイヤー定義はゆるめ
 
 
 
 

13. © DMM コンポーネント構成選定
 13 13 選定理由
 
 　・学習コストが低く、チーム全員で理解しやすい
 
 　・コンポーネント階層構造がわかりやすく依存関係が把握しやすい
 
 　・機能単位のフォルダ + グローバル共有の大枠で柔軟性を確保
 
 　・FSDほど厳密なレイヤー定義がないため、将来の仕様変更にも対応しやすい
 
 
 
 

14. © DMM 話すこと
 14 14 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 

15. © DMM Bulletproof React の構造例 (Feature) 
 
 
 実際のディレクトリ構成と責務の整理
 15 15
16. © DMM ディレクトリ構成（アプリ基盤 & 機能スコープ） 
 
 
 実際のディレクトリ構成と責務の整理
 16 16
17. © DMM 実際のディレクトリ構成と責務の整理
 17 17 feature1 widgets1 shared pages feature2 feature3 widgets2 全機能で再利用される共通 基盤
 api / components / utils を 配置 機能単位でビジネスロジック & UI をまとめる
 api / components / hooks / store を内包
 複数の features を組み合わ せた UI の塊
 pagesでのみ再利用可能 
 ルーティング単位
 feature や widget を組み合 わせたUI

18. © DMM 話すこと
 18 18 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 

19. © DMM 実装例 (features)
 
 
 19 19
20. © DMM 実装例 (widgets & pages)
 
 
 20 20
21. © DMM 話すこと
 21 21 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 

22. © DMM 効果
 
 • 機能の所在が明確になり、理解しやすい
 • ルールに基づき「どこで何をやるか」が整理されやすい
 • Atomic Designより秩序ある構成に改善
 • リアーキテクトと同時に構成を見直したことで、開発体験が向上しモダンな記法が可 能に (副産物)
 効果と課題
 22 22
23. © DMM 課題
 
 • ドキュメントやルールがAtomic Designほど確立されていない 
 • featureの粒度が開発者ごとにバラバラ 
 • feature間依存を禁止するルールを一部で逸脱 
 • widgetの粒度・まとめ方が曖昧
 • sharedに「とりあえず置く」が多発
 効果と課題
 23 23
24. © DMM 話すこと
 24 24 1. 課題と背景
 2. コンポーネント構成選定
 3. 実際のディレクトリ構成と責務の整理
 4. 実装例
 5. 効果と課題
 6. まとめ
 

25. © DMM ・開発体験が向上し、機能の所在が把握しやすくなった
 
 ・ルールとアーキテクチャ構成はさらに厳格に整備する必要あり
 
 ・BulletProofは自由度が高いため、チーム内でのルール決定が重要
 
 ・今後は残課題の解決に向けた運用ルールの整備を推進
 
 
 まとめ
 25 25 　俺たちの戦いはこれからだ！
26. © DMM ご清聴ありがとうございました 🙇