Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アイテムレビュー基盤で導入したアーキテクチャとその成果 / Item Review Introduction Architecture Outcome
Search
chiharu terashima
May 21, 2024
Programming
1
2.4k
アイテムレビュー基盤で導入したアーキテクチャとその成果 / Item Review Introduction Architecture Outcome
2024-05-22 アーキテクチャを突き詰める Online Conference
〜企業事例LTセッション〜
https://findy.connpass.com/event/314782/
chiharu terashima
May 21, 2024
Tweet
Share
More Decks by chiharu terashima
See All by chiharu terashima
SpringBootとKtorを雑に比較してみる
chichi1091
1
680
Other Decks in Programming
See All in Programming
Product Management LT会_クアンド新家
shinshin
0
210
Terraformテスト入門
msato
0
520
スクラムマスターって孤独じゃないですか?
yoshitaroyoyo
1
140
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
81k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
7
3k
Rustのweb開発を助ける 便利なツール紹介
yuki0418
1
190
AHC035解説
terryu16
0
710
Mastering Developer Experience: A Roadmap for Success 【開発生産性Conference 2024】
findyinc
1
380
From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
ivargrimstad
0
1.9k
リハビリmruby
kishima
1
160
小さな開発会社を作った理由
polidog
0
1.9k
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがやばい #mackerelio #srenext
ne_sachirou
0
370
Featured
See All Featured
Leading Effective Engineering Teams 2024
addyosmani
3
300
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.4k
Agile that works and the tools we love
rasmusluckow
325
20k
YesSQL, Process and Tooling at Scale
rocio
166
14k
A designer walks into a library…
pauljervisheath
201
24k
It's Worth the Effort
3n
181
27k
The Invisible Side of Design
smashingmag
294
50k
Building an army of robots
kneath
301
42k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Speed Design
sergeychernyshev
9
270
Being A Developer After 40
akosma
72
580k
Principles of Awesome APIs and How to Build Them.
keavy
124
16k
Transcript
アイテムレビュー基盤で導入した アーキテクチャとその成果 2024-05-22 アーキテクチャを突き詰める Online Conference 〜企業事例LTセッション〜 株式会社ZOZO 技術本部 ECプラットフォーム部
マイグレーションブロック 寺嶋 千晴 Copyright © ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO 技術本部 ECプラットフォーム部 マイグレーションブロック 寺嶋 千晴 2022年に株式会社ZOZOに入社しZOZOTOWNの
リプレイス業務を行っています。 家族6人+トイプードルと長野県で暮らしています。 2
© ZOZO, Inc. https://zozo.jp/ 3 • ファッションEC • 1,500以上のショップ、9,000以上のブランドの取り扱い •
常時102万点以上の商品アイテム数と毎日平均2,600点以上の新 着 商品を掲載(2024年3月末時点) • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、靴の専門モール 「ZOZOSHOES」、ラグジュアリー&デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
© ZOZO, Inc. 4 2023年11月にアイテムレビュー機能がリリース!
© ZOZO, Inc. 5 アイテムレビューとは?
© ZOZO, Inc. 6 アイテムレビューとは?
© ZOZO, Inc. どのようにアイテムレビュー基盤を 構築していったか? 7
© ZOZO, Inc. 8 開発時の課題 • (大人の事情で)基盤の開発だけが先行開発することになる ◦ 構築完了後ぐらいに他チームが動き出す ▪
コミュニケーション不足による認識齟齬 ▪ 設計の不整合に気が付けない ◦ →結果、これらが原因でのちのち仕様変更・調整が入る可能性が🥺 • 他にも ◦ ZOZOTOWNだけでなく社内システムからも利用される ◦ チームの特性上、コアなドメイン扱うチームである
© ZOZO, Inc. 9 どうしよう?よし、こうしよう! • 仕様変更は入ることを受け入れて如何に手早く・品質担保して機能を提供するか ◦ そのためには変更容易性を高めることが必要 •
解決案としてドメイン駆動設計を行うことにした
© ZOZO, Inc. 10 とは言うものの • アイテムレビューを理解しているドメインエキスパートはいない ◦ 戦術的DDDを行うことになる •
戦術的DDDとは? ◦ ドメイン駆動設計の技術的要素のみを活用した手法 ◦ 実装パターン:エンティティ、値オブジェクト、リポジトリなど ◦ レイヤー設計:クリーンアーキテクチャ、オニオンアーキテクチャなど • 仕様変更を受け入れやすくするという観点から戦術的DDDも有効であると判断した
© ZOZO, Inc. 具体的にどのように行ったか? 11
© ZOZO, Inc. 12 設計で行ったこと • ユースケースの可視化 ◦ 基盤用ではなくアイテムレビュー全体像を整理することが目的 ◦
ユースケース単位で工数精査を行うことで各チームの粒度が揃う ◦ 会話の共通認識となる
© ZOZO, Inc. 13 設計で行ったこと • シーケンス図の作成 ◦ ユースケース単位で作成 ◦
どのマイクロサービスを利用するのか? ◦ どのようなAPIが必要となるのか? ◦ 負荷試験ではどのようなデータが必要になるのか
© ZOZO, Inc. 14 設計で行ったこと • ドメインモデル図 ◦ モブプロ形式で作成 ◦
ドメイン知識の共有
© ZOZO, Inc. 15 実装に向けて • まずはアーキテクチャの選定 ◦ Q. アーキテクチャはなにを選ぼう?
◦ A. オニオンアーキテクチャが最適そう ▪ 他マイクロサービスでも採用されてて馴染みがある(参考) ▪ ドメインを中心としていて理解がしやすい ▪ ドメインモデルにビジネス要件を反映しやすい • DDDが推奨するアーキテクチャの本質は同じではあるが、複数マイクロサービスを管 理・運営するのに複数のアーキテクチャは混乱してしまいそう
© ZOZO, Inc. 16 パッケージレイヤー • プレゼンテーション層:APIの公開とユースケース層とのデータ変換 • ユースケース層:シナリオの組み立て、トランザクションの制御 •
ドメイン層:ドメイン知識、集約単位でデータ整合性の担保 • インフラストラクチャー層:外部サービス(主にDB)へのアクセス
© ZOZO, Inc. 17 参考にさせていただいたサイトや書籍 引用元:ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 引用元:ドメイン駆動設計入門 https://www.shoeisha.co.jp/book/detail/9784798150727
• ドメイン駆動設計で実装を始めるの に一番とっつきやすいアーキテク チャは何か[DDD] • 実践クリーンアーキテクチャ with Java
© ZOZO, Inc. 18 やってみてどうだった? • ユースケース、シーケンス図という共通認識でコミュニケーションがしやすい ◦ 開発者だけでなくPMやSREとも会話がしやすかった •
懸念通り仕様変更は入ったが ◦ 責務が明確になっていることで修正箇所が限定的 ◦ ユニットテストも書きやすいためスピーディな対応 ◦ 影響箇所調査と再テストで疲弊するといったことも起きない • 基盤技術の共有 ◦ リプレイスプロジェクトはまだまだ続くためこれからも新たな基盤が作られる ◦ アイテムレビューのノウハウを詰め込んだTemplateリポジトリを作成 ◦ 新たな技術挑戦の場、社内勉強会の題材などにも活用
© 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
© ZOZO, Inc. 20 失敗や反省 • APIのI/F設計をwikiで行い、途中でOpenAPIに切り替えたことで2重管理になり混乱が 生じてしまった ◦ →最初からOpenAPIでコミュニケーションするように改善
• ドメインモデルの実装に時間がかかりPullRequestが大きくなる ◦ →自分が必要な部分のみ実装して細かく、数多くPullRequestを出す • ユビキタス言語をしっかりと定めなかった ◦ →ちょっとしたことでもリストに上げよう
© ZOZO, Inc. 21 まとめ • 先行開発だったからこそより仕様変更を受け入れる心構えができチームで取り組めた • 戦術的DDDの導入で変更容易性の高いマイクロサービスが構築できた ◦
実際に予想より早い修正が行えた ◦ モブドメインモデリングが楽しい • コミュニケーションのための設計資料も改めて大事だと実感 ◦ 設計者間だけでなく負荷試験設計にも活用できた • Templateリポジトリでマイクロサービス立ち上げもスピーディ ◦ 複数の基盤でこのリポジトリから立ち上げている ◦ チームメンバーが積極的に得られた知見をFBしてくれている
None