Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~

826 views

Published on

Developers Boost KANSAI (2019.6.15 @Osaka) の発表資料です。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

大規模フロントエンドのクリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~

  1. 1. 大規模フロントエンドの クリーンアーキテクチャ化 ~ 年間売上1,000億円企業モノタロウの取組み ~ 12019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved. 株式会社MonotaRO データマーケティング部門 芝本 雅史
  2. 2. 次のどれかに悩んでいる人 ● 複雑に依存しているシステム ● 技術的負債を抱えているシステム ● テストコードがないシステム 2 対象者
  3. 3. CleanArchitectureについて ● 詳しく知らなくても学びながら作れる 3 もちかえってほしいこと
  4. 4. アジェンダ 4 ● 自己紹介 ● 背景 ● CleanArchitectureとは? ● 取り組んで得た知見 ● まとめ
  5. 5. 自己紹介 5
  6. 6. 氏名 芝本 雅史 (shibamoto masashi) 誕生日 1994/02/14 出身 大阪 会社 株式会社MonotaRO データマーケティング部門 趣味 個人開発 興味 K8s,GCP,MicroFrontends twitter silver_birder portfolio https://silver-birder.github.io 自己紹介 6
  7. 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. 背景 8
  9. 9. 9 急成長するモノタロウだが...
  10. 10. 10 急成長についていけてないものがある...
  11. 11. 11 背景 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  12. 12. 12 背景 Python shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  13. 13. 13 背景 Python 独自MVC フレームワーク (テストコードなし) shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  14. 14. 14 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  15. 15. 15 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  16. 16. 16 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 shibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  17. 17. 17 独自フレームワークから 脱却しないと...!
  18. 18. 18 独自フレームワークがシステムと 密結合していて無理...
  19. 19. 19 テストコードがないから不安...
  20. 20. 20 そんなときに!
  21. 21. 21 背景 Python 独自MVC フレームワーク (テストコードなし) 技術的負債 新機能拡張 独自MVC フレームワーク 開発者の退職 cleanArchitectureshibamoto MonotaRO FrontEnd ServerSide - Search Page  my mental capacity
  22. 22. CleanArchitectureとは? 22
  23. 23. 23 CleanArchitecture 特徴 関心の分離 一方向への依存関係 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  24. 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. 25. ● データベースやWebフレームワークの詳細 ○ ex. ■ databaseへの接続設定 ■ Webフレームワークの設定 25 関心の分離 - Frameworks & Drivers -
  26. 26. ● 外→内 ○ 外部アクセスからユースケースを呼び出し ■ ex. ● MVCの Controller ● 内→外 ○ Enterpriseのデータを外部へ適した形に変換 ■ ex. ● MVCのView (Presenter) 26 関心の分離 - Interface Adapters -
  27. 27. ● アプリケーション固有のビジネスルールを カプセル化 ● データベース,UI,フレームワークから隔離 ○ ex. ■ キーワードから商品を検索するユースケース ■ ユーザー情報を登録するユースケース 27 関心の分離 - Application Business Rules -
  28. 28. ● 企業全体のビジネスルールをカプセル化 ● データとメソッドを持つ ○ ex. ■ 商品情報のドメイン ● メソッド:特価の商品か判断する ■ ユーザー情報のドメイン ● メソッド:〇企業に属するか判断する 28 関心の分離 - Enterprise Business Rules -
  29. 29. ● 依存関係逆転の原則 ○ dependency inversion principle 29 一方向への依存関係
  30. 30. 30 依存関係逆転の原則 ※ https://ja.wikipedia.org/wiki/依存性逆転の原則 before
  31. 31. 31 依存関係逆転の原則 after ※ https://ja.wikipedia.org/wiki/依存性逆転の原則
  32. 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. 33. ● テスト可能 ○ Testable 33 CleanArchitectureの良い面 ※ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
  34. 34. ● ソースコードのファイルが増える ○ 処理を追う時間がかかる 34 CleanArchitectureの悪い面
  35. 35. UIでは「Atomic Designによるコンポーネント 化」に取り組みました。 ※ 今回は話しません。 35 CleanArchitecture以外の取り組み
  36. 36. 取り組んで得た知見 36
  37. 37. 1. 学習しながら開発 2. リリースを分割 3. 本質的なことに集中 4. テストの手段 37 取り組んで得た知見
  38. 38. ● 先に幹となる処理を書いて、後から枝葉と なる処理を書くこと ○ 根本となる設計から始められる 38 1. 学習しながら開発
  39. 39. CleanArchitectureって、 どこから開発したら良いんだ..? 39 1. 学習しながら開発
  40. 40. チームでCleanArchitectureについて 詳しい人はいないし... 40 1. 学習しながら開発
  41. 41. 最初から最後までを1本通して 作ってみよう 41 1. 学習しながら開発
  42. 42. 42 1. 学習しながら開発 Controller Use Case Entity Presenter 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索
  43. 43. 43 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索
  44. 44. 44 1. 学習しながら開発 Controller Use Case Entity Presenter Use Case Entity Use Case 先に幹となる処理を書いて、後から枝葉となる処理を書く キーワードから商品を検索 カテゴリから商品を検索 価格から商品を検索
  45. 45. ● CleanArchitectureを学習しながら、段階的 に作成可能 ○ 最初から完璧に設計するのが難しい ○ 試行錯誤→理想形 ● デバッグが容易 ○ アプリケーションの動作確認がしやすい 45 1. 学習しながら開発
  46. 46. ● エンドポイント毎にリリースする等のリ リース規模を分割すること ○ メンテナンスコストを削減するため 46 2. リリースを分割
  47. 47. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 47 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト 検索ページ - CleanArchitecture化 before/after
  48. 48. ● ソースコード ○ 約3,000行 ○ 約10ファイル ■ プロダクト 48 2. リリースを分割 ● ソースコード ○ 約15,000行 ○ 約300ファイル ■ 約150ファイル ● プロダクト ■ 約150ファイル ● テスト設計&実装に10人月 テストに6人月 検索ページ - CleanArchitecture化 before/after
  49. 49. とにかく開発に時間がかかる! 49 2. リリースを分割
  50. 50. 大量の変更ファイルを維持するのは大変 早くリリースしたい... 50 2. リリースを分割
  51. 51. リリースを早くするのには...? 51 2. リリースを分割
  52. 52. リリースをエンドポイント毎に分割しよう 52 2. リリースを分割
  53. 53. 53 2. リリースを分割 Routing requeast 特集ページ 検索ページ 商品ページ
  54. 54. 54 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ 商品ページ release
  55. 55. 55 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ (CleanArchitecture化) 商品ページ release release
  56. 56. 56 2. リリースを分割 Routing requeast 特集ページ (CleanArchitecture化) 検索ページ (CleanArchitecture化) 商品ページ (CleanArchitecture化) release release release
  57. 57. ● トラブルの原因調査が比較的簡単 ○ ロールバックがしやすい ● アプリケーションのサービス提供をしなが ら開発可能 ○ 新機能追加のタイミングが調整しやすい 57 2. リリースを分割
  58. 58. ● 本質的な部分以外に時間をかけないこと ○ 開発工数を抑えるため 58 3. 本質的なことに集中
  59. 59. 本質的 ● 独自フレームワークからの脱却 ● テストコード作成 59 3. 本質的なことに集中
  60. 60. 非本質的 ● ユースケースの返り値はEntityの型 ● Entityは不変オブジェクト ● Presenterにセットした値を取得する手段 ● ...etc 60 3. 本質的なことに集中
  61. 61. ● CleanArchitectureが目的ではない ○ 何がしたいのかよく考えること ● リファクタリングが容易 ○ テストコードがあるから 61 3. 本質的なことに集中
  62. 62. ● スナップショットテストを活用 ○ 効率的に品質を高めるため ○ ex. ■ Jest, Puppeteer 62 4. テストの手段
  63. 63. システムリプレースのテストは どうするの? 63 4. テストの手段
  64. 64. 大規模なシステムだと、一からテスト 仕様書を書いて進めるのは非効率 64 4. テストの手段
  65. 65. ● 「HTMLが変わってないこと」に着目 ↓ スナップショットツールの活用 65 4. テストの手段
  66. 66. 66 4. テストの手段 基本パターン URLリスト 検索ページ (CleanArchitecture前) 検索ページ (CleanArchitecture後) requeast HTML HTML requeast diff 機能網羅 スナップショットツールの流れ
  67. 67. 67 4. テストの手段 ランダムパターン URLリスト 検索ページ (CleanArchitecture前) 検索ページ (CleanArchitecture後) requeast HTML HTML requeast diff アクセスログ スナップショットツールの流れ
  68. 68. ● テスト工程が簡単 ○ テスト→バグ修正を繰り返す ● 非機能要件は別途テストが必要 ○ プロファイリング ○ 負荷テスト 68 4. テストの手段
  69. 69. 取り組んだ結果 Q1. 独自フレームワークからの脱却は? A1. 独自フレームワークの処理をFrameworks & Drivers層 に寄せたことで、他のフレームワークと切り替えれるよう になった。 フレームワークに求める機能を整理することができたた め、新たなフレームワークを採用する際に役立つ。 69
  70. 70. 取り組んだ結果 Q2. テストコードは? A2. プロダクションコードと同じぐらいの行数のテスト コードを生成できた。 インターフェースをMockで差し替えるだけで、テスト コードが容易に生成できる。また、一方向へ依存している ため、上の層を気にしなくて済む。結果、テストコードに 集中できる。 70
  71. 71. 取り組んだ結果 Q3. 悪かったことは? A3. 開発工数が予定以上に膨れてしまった。(約1.6倍) 原因の1つは、「CleanArchitectureの理解」と「業務知 識の理解」を並走して開発したため。結果、スピードが低 下した。 → 業務知識の理解者がメンバーにいると良い。 71
  72. 72. 取り組んだ結果 Q4. 良かったことは? A4. 複雑だったコードが、適切な層に配置されたことで、 コードの見通しが良くなった。 ユースケースの種類や順序が明確になるので、 仕様を把握しやすくなった。結果、保守しやすくなった。 72
  73. 73. まとめ ● 依存フレームワークからの脱却する道筋が立った ● 開発工数が大幅に膨らんでしまう問題がある ● CleanArchitectureに詳しい人がチームにいなくて もなんとかなる! 73
  74. 74. 急成長するモノタロウと一緒に働いてみませんか? ● 自社開発・自社運用で、全社/全業務でITを駆使するテ クノロジー企業です。テックブログもやってます。 ● 本社は関西(尼崎)で、幅広い職種を募集しています。 ○ ITエンジニア、データサイエンティスト、デジタル マーケター、プロダクトマネージャー ● お気軽にご連絡ください。 ○ shibamoto@monotaro.com 74
  75. 75. 752019.06.15 © 2019 MonotaRO Co., Ltd. All Rights Reserved.

×