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 Intro...
Search
chiharu terashima
May 21, 2024
Programming
1
3.2k
アイテムレビュー基盤で導入したアーキテクチャとその成果 / 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
790
Other Decks in Programming
See All in Programming
Django for Data Science (Boston Python Meetup, March 2025)
wsvincent
0
310
Deoptimization: How YJIT Speeds Up Ruby by Slowing Down / RubyKaigi 2025
k0kubun
0
150
DataStoreをテストする
mkeeda
0
280
AI Coding Agent Enablement - エージェントを自走させよう
yukukotani
13
5.6k
PHPUnit 高速化テクニック / PHPUnit Speedup Techniques
pinkumohikan
1
1.4k
The Weight of Data: Rethinking Cloud-Native Systems for the Age of AI
hollycummins
0
260
Firebase Dynamic Linksの代替手段を自作する / Create your own Firebase Dynamic Links alternative
kubode
0
230
MCP調べてみました! / Exploring MCP
uhzz
2
2.2k
CRE Meetup!ユーザー信頼性を支えるエンジニアリング実践例の発表資料です
tmnb
0
620
新しいPHP拡張モジュールインストール方法「PHP Installer for Extensions (PIE)」を使ってみよう!
cocoeyes02
0
230
Chrome Extension Techniques from Hell
moznion
1
160
英語 × の私が、生成AIの力を借りて、OSSに初コントリビュートした話
personabb
0
180
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.4k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Done Done
chrislema
183
16k
Six Lessons from altMBA
skipperchong
27
3.7k
Statistics for Hackers
jakevdp
798
220k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
740
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
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