アイテムレビュー基盤で導入したアーキテクチャとその成果 / Item Review Introduction Architecture Outcome

2024-05-22 アーキテクチャを突き詰める Online Conference
〜企業事例LTセッション〜
https://findy.connpass.com/event/314782/

1. アイテムレビュー基盤で導入した アーキテクチャとその成果 2024-05-22 アーキテクチャを突き詰める Online Conference 　〜企業事例LTセッション〜 株式会社ZOZO
 技術本部 ECプラットフォーム部 マイグレーションブロック
 寺嶋 千晴 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 技術本部 ECプラットフォーム部 マイグレーションブロック 寺嶋 千晴 2022年に株式会社ZOZOに入社しZOZOTOWNの リプレイス業務を行っています。 家族６人＋トイプードルと長野県で暮らしています。 2
3. © ZOZO, Inc. https://zozo.jp/ 3 • ファッションEC • 1,500以上のショップ、9,000以上のブランドの取り扱い • 常時102万点以上の商品アイテム数と毎日平均2,600点以上の新 着 商品を掲載（2024年3月末時点） • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、靴の専門モール 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
4. © ZOZO, Inc. 4 2023年11月にアイテムレビュー機能がリリース！
5. © ZOZO, Inc. 5 アイテムレビューとは？
6. © ZOZO, Inc. 6 アイテムレビューとは？
7. © ZOZO, Inc. どのようにアイテムレビュー基盤を 構築していったか？ 7
8. © ZOZO, Inc. 8 開発時の課題 • (大人の事情で)基盤の開発だけが先行開発することになる ◦ 構築完了後ぐらいに他チームが動き出す ▪ コミュニケーション不足による認識齟齬 ▪ 設計の不整合に気が付けない ◦ →結果、これらが原因でのちのち仕様変更・調整が入る可能性が🥺 • 他にも ◦ ZOZOTOWNだけでなく社内システムからも利用される ◦ チームの特性上、コアなドメイン扱うチームである
9. © ZOZO, Inc. 9 どうしよう？よし、こうしよう！ • 仕様変更は入ることを受け入れて如何に手早く・品質担保して機能を提供するか ◦ そのためには変更容易性を高めることが必要 • 解決案としてドメイン駆動設計を行うことにした
10. © ZOZO, Inc. 10 とは言うものの • アイテムレビューを理解しているドメインエキスパートはいない ◦ 戦術的DDDを行うことになる • 戦術的DDDとは？ ◦ ドメイン駆動設計の技術的要素のみを活用した手法 ◦ 実装パターン：エンティティ、値オブジェクト、リポジトリなど ◦ レイヤー設計：クリーンアーキテクチャ、オニオンアーキテクチャなど • 仕様変更を受け入れやすくするという観点から戦術的DDDも有効であると判断した
11. © ZOZO, Inc. 具体的にどのように行ったか？ 11
12. © ZOZO, Inc. 12 設計で行ったこと • ユースケースの可視化 ◦ 基盤用ではなくアイテムレビュー全体像を整理することが目的 ◦ ユースケース単位で工数精査を行うことで各チームの粒度が揃う ◦ 会話の共通認識となる
13. © ZOZO, Inc. 13 設計で行ったこと • シーケンス図の作成 ◦ ユースケース単位で作成 ◦ どのマイクロサービスを利用するのか？ ◦ どのようなAPIが必要となるのか？ ◦ 負荷試験ではどのようなデータが必要になるのか
14. © ZOZO, Inc. 14 設計で行ったこと • ドメインモデル図 ◦ モブプロ形式で作成 ◦ ドメイン知識の共有
15. © ZOZO, Inc. 15 実装に向けて • まずはアーキテクチャの選定 ◦ Q. アーキテクチャはなにを選ぼう？ ◦ A. オニオンアーキテクチャが最適そう ▪ 他マイクロサービスでも採用されてて馴染みがある（参考） ▪ ドメインを中心としていて理解がしやすい ▪ ドメインモデルにビジネス要件を反映しやすい • DDDが推奨するアーキテクチャの本質は同じではあるが、複数マイクロサービスを管 理・運営するのに複数のアーキテクチャは混乱してしまいそう
16. © ZOZO, Inc. 16 パッケージレイヤー • プレゼンテーション層：APIの公開とユースケース層とのデータ変換 • ユースケース層：シナリオの組み立て、トランザクションの制御 • ドメイン層：ドメイン知識、集約単位でデータ整合性の担保 • インフラストラクチャー層：外部サービス（主にDB）へのアクセス
17. © ZOZO, Inc. 17 参考にさせていただいたサイトや書籍 引用元：ドメイン駆動設計 モデリング／実装ガイド https://little-hands.booth.pm/items/1835632 引用元：ドメイン駆動設計入門 https://www.shoeisha.co.jp/book/detail/9784798150727 • ドメイン駆動設計で実装を始めるの に一番とっつきやすいアーキテク チャは何か[DDD] • 実践クリーンアーキテクチャ with Java
18. © ZOZO, Inc. 18 やってみてどうだった？ • ユースケース、シーケンス図という共通認識でコミュニケーションがしやすい ◦ 開発者だけでなくPMやSREとも会話がしやすかった • 懸念通り仕様変更は入ったが ◦ 責務が明確になっていることで修正箇所が限定的 ◦ ユニットテストも書きやすいためスピーディな対応 ◦ 影響箇所調査と再テストで疲弊するといったことも起きない • 基盤技術の共有 ◦ リプレイスプロジェクトはまだまだ続くためこれからも新たな基盤が作られる ◦ アイテムレビューのノウハウを詰め込んだTemplateリポジトリを作成 ◦ 新たな技術挑戦の場、社内勉強会の題材などにも活用
19. © ZOZO, Inc. 19 失敗や反省 • リポジトリの誤った利用で集約・モデルを無視したデータ更新 ◦ →チーム内の輪読会で理解を深める 引用元：セキュア・バイ・デザイン https://book.mynavi.jp/ec/products/detail/id=124056 引用元：現在で役立つシステム設計の原則 https://gihyo.jp/book/2017/978-4-7741-9087-7 引用元：ドメイン駆動設計 モデリング／実装ガイド https://little-hands.booth.pm/items/1835632
20. © ZOZO, Inc. 20 失敗や反省 • APIのI/F設計をwikiで行い、途中でOpenAPIに切り替えたことで2重管理になり混乱が 生じてしまった ◦ →最初からOpenAPIでコミュニケーションするように改善 • ドメインモデルの実装に時間がかかりPullRequestが大きくなる ◦ →自分が必要な部分のみ実装して細かく、数多くPullRequestを出す • ユビキタス言語をしっかりと定めなかった ◦ →ちょっとしたことでもリストに上げよう
21. © ZOZO, Inc. 21 まとめ • 先行開発だったからこそより仕様変更を受け入れる心構えができチームで取り組めた • 戦術的DDDの導入で変更容易性の高いマイクロサービスが構築できた ◦ 実際に予想より早い修正が行えた ◦ モブドメインモデリングが楽しい • コミュニケーションのための設計資料も改めて大事だと実感 ◦ 設計者間だけでなく負荷試験設計にも活用できた • Templateリポジトリでマイクロサービス立ち上げもスピーディ ◦ 複数の基盤でこのリポジトリから立ち上げている ◦ チームメンバーが積極的に得られた知見をFBしてくれている