大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~
•
2 likes•4,485 views
Developers Boost KANSAI (2019.6.15 @Osaka) の発表資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~
Similar to 大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~ (20)
More from 株式会社MonotaRO Tech Team
More from 株式会社MonotaRO Tech Team (20)
Recently uploaded
Recently uploaded (16)
大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~
- 1. 大規模フロントエンドの クリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~ 12019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved. 株式会社MonotaRO データマーケティング部門 芝本 雅史
- 2. 次のどれかに悩んでいる人 ● 複雑に依存しているシステム ● 技術的負債を抱えているシステム ● テストコードがないシステム 2 対象者
- 4. アジェンダ 4 ● 自己紹介 ● 背景 ● CleanArchitectureとは? ● 取り組んで得た知見 ● まとめ
- 5. 自己紹介 5
- 6. 氏名 芝本 雅史 (shibamoto masashi) 誕生日 1994/02/14 出身 大阪 会社 株式会社MonotaRO データマーケティング部門 趣味 個人開発 興味 K8s,GCP,MicroFrontends twitter silver_birder portfolio https://silver-birder.github.io 自己紹介 6
- 7. 株式会社モノタロウ 7 ● 事業者向けに提供する間接資材の通信販売会社 ● 年間売上1,053億円の売上 (2018年) ○ 前年比24.0%↑ ■ 2019年売上計画1,305億円 ○ 9年連続20%↑の成長率 (2009年~)※ ※ https://pdf.irpocket.com/C3064/g9xd/i8RW/uNIX.pdf no.7 システムは主にPython
- 8. 背景 8
- 11. 11 背景 shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 12. 12 背景 Python shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 13. 13 背景 Python 独自MVC フレームワーク (テストコードなし) shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 14. 14 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 15. 15 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 16. 16 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 shibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 20. 20 そんなときに！
- 21. 21 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 cleanArchitectureshibamoto MonotaRO FrontEnd ServerSide - Search Page my mental capacity
- 24. 24 CleanArchitecture レイヤー名 役割 Frameworks & Drivers DBやフレームワークの詳細 Interface Adapters 内外へのデータ変換 Application Business Rules アプリケーション固有のビジネ スルールをカプセル化 Enterprice Business Rules 企業全体のビジネスルールを カプセル化 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 25. ● データベースやWebフレームワークの詳細 ○ ex. ■ databaseへの接続設定 ■ Webフレームワークの設定 25 関心の分離 - Frameworks & Drivers -
- 26. ● 外→内 ○ 外部アクセスからユースケースを呼び出し ■ ex. ● MVCの Controller ● 内→外 ○ Enterpriseのデータを外部へ適した形に変換 ■ ex. ● MVCのView (Presenter) 26 関心の分離 - Interface Adapters -
- 27. ● アプリケーション固有のビジネスルールを カプセル化 ● データベース,UI,フレームワークから隔離 ○ ex. ■ キーワードから商品を検索するユースケース ■ ユーザー情報を登録するユースケース 27 関心の分離 - Application Business Rules -
- 28. ● 企業全体のビジネスルールをカプセル化 ● データとメソッドを持つ ○ ex. ■ 商品情報のドメイン ● メソッド：特価の商品か判断する ■ ユーザー情報のドメイン ● メソッド：〇企業に属するか判断する 28 関心の分離 - Enterprise Business Rules -
- 29. ● 依存関係逆転の原則 ○ dependency inversion principle 29 一方向への依存関係
- 32. ● フレームワークからの独立 ○ Independent of Frameworks ● データベースからの独立 ○ Independent of Database ● UIからの独立 ○ Independent of UI 32 CleanArchitectureの良い面 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 33. ● テスト可能 ○ Testable 33 CleanArchitectureの良い面 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 35. UIでは「Atomic Designによるコンポーネント 化」に取り組みました。 ※ 今回は話しません。 35 CleanArchitecture以外の取り組み
- 36. 取り組んで得た知見 36
- 37. 1. 学習しながら開発 2. リリースを分割 3. 本質的なことに集中 4. テストの手段 37 取り組んで得た知見
- 42. 42 1. 学習しながら開発 Controller Use Case Entity Presenter 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索
- 43. 43 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索
- 44. 44 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity Use Case 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索 価格から商品を検索
- 45. ● CleanArchitectureを学習しながら、段階的 に作成可能 ○ 最初から完璧に設計するのが難しい ○ 試行錯誤→理想形 ● デバッグが容易 ○ アプリケーションの動作確認がしやすい 45 1. 学習しながら開発
- 47. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 47 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト 検索ページ - CleanArchitecture化 before/after
- 48. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 48 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト設計&実装に10人月 テストに6人月 検索ページ - CleanArchitecture化 before/after
- 57. ● トラブルの原因調査が比較的簡単 ○ ロールバックがしやすい ● アプリケーションのサービス提供をしなが ら開発可能 ○ 新機能追加のタイミングが調整しやすい 57 2. リリースを分割
- 58. ● 本質的な部分以外に時間をかけないこと ○ 開発工数を抑えるため 58 3. 本質的なことに集中
- 59. 本質的 ● 独自フレームワークからの脱却 ● テストコード作成 59 3. 本質的なことに集中
- 60. 非本質的 ● ユースケースの返り値はEntityの型 ● Entityは不変オブジェクト ● Presenterにセットした値を取得する手段 ● ...etc 60 3. 本質的なことに集中
- 61. ● CleanArchitectureが目的ではない ○ 何がしたいのかよく考えること ● リファクタリングが容易 ○ テストコードがあるから 61 3. 本質的なことに集中
- 62. ● スナップショットテストを活用 ○ 効率的に品質を高めるため ○ ex. ■ Jest, Puppeteer 62 4. テストの手段
- 68. ● テスト工程が簡単 ○ テスト→バグ修正を繰り返す ● 非機能要件は別途テストが必要 ○ プロファイリング ○ 負荷テスト 68 4. テストの手段
- 69. 取り組んだ結果 Q1. 独自フレームワークからの脱却は？ A1. 独自フレームワークの処理をFrameworks & Drivers層 に寄せたことで、他のフレームワークと切り替えれるよう になった。 フレームワークに求める機能を整理することができたた め、新たなフレームワークを採用する際に役立つ。 69
- 71. 取り組んだ結果 Q3. 悪かったことは？ A3. 開発工数が予定以上に膨れてしまった。(約1.6倍) 原因の1つは、「CleanArchitectureの理解」と「業務知 識の理解」を並走して開発したため。結果、スピードが低 下した。 → 業務知識の理解者がメンバーにいると良い。 71
- 73. まとめ ● 依存フレームワークからの脱却する道筋が立った ● 開発工数が大幅に膨らんでしまう問題がある ● CleanArchitectureに詳しい人がチームにいなくて もなんとかなる！ 73
- 74. 急成長するモノタロウと一緒に働いてみませんか？ ● 自社開発・自社運用で、全社/全業務でITを駆使するテ クノロジー企業です。テックブログもやってます。 ● 本社は関西(尼崎)で、幅広い職種を募集しています。 ○ ITエンジニア、データサイエンティスト、デジタル マーケター、プロダクトマネージャー ● お気軽にご連絡ください。 ○ shibamoto@monotaro.com 74
- 75. 752019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved.