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
2.6k
アイテムレビュー基盤で導入したアーキテクチャとその成果 / 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
690
Other Decks in Programming
See All in Programming
労務ドメインを快適に開発する方法 / How to Comfortably Develop in the Labor Domain
yuki21
1
250
The Sequel to a Dream of Ruby Parser's Grammar
ydah
1
180
iOSDC 2024
auramagi
3
590
Hono・Prisma・AWSでGeoなAPI開発
nokonoko1203
5
610
開発を加速する共有Swift Package実践
elmetal
PRO
0
300
New Order in Cascade Sorting Order
mugi_uno
3
2.5k
dotfiles について話したい #湘なんか
stefafafan
2
280
ゲームボーイアドバンスでSwiftを動かそう
k_koheyi
0
510
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
1
930
仮想ファイルシステムを導入して開発環境のストレージ課題を解消する
segadevtech
2
390
Some more adventure of Happy Eyeballs
coe401_
2
150
2024 컴포즈 정원사
jisungbin
0
140
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
35
6.9k
Building Your Own Lightsaber
phodgson
101
5.9k
Optimizing for Happiness
mojombo
375
69k
Six Lessons from altMBA
skipperchong
26
3.3k
Statistics for Hackers
jakevdp
793
220k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Intergalactic Javascript Robots from Outer Space
tanoku
268
26k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Code Reviewing Like a Champion
maltzj
518
39k
Ruby is Unlike a Banana
tanoku
96
10k
We Have a Design System, Now What?
morganepeng
48
7.1k
The Cult of Friendly URLs
andyhume
76
5.9k
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