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
技術選定を未来に繋いで活用していく
sakito
3
100
自分のために作ったアプリが、グローバルに使われるまで / Indie App Development Lunch LT
pixyzehn
1
150
リアルタイムレイトレーシング + ニューラルレンダリング簡単紹介 / Real-Time Ray Tracing & Neural Rendering: A Quick Introduction (2025)
shocker_0x15
1
280
フロントエンドテストの育て方
quramy
11
2.9k
The Weight of Data: Rethinking Cloud-Native Systems for the Age of AI
hollycummins
0
250
Fluent UI Blazor 5 (alpha)の紹介
tomokusaba
0
170
メモリウォールを超えて:キャッシュメモリ技術の進歩
kawayu
0
1.8k
「影響が少ない」を自分の目でみてみる
o0h
PRO
2
840
AIコードエディタの基盤となるLLMのFlutter性能評価
alquist4121
0
190
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
390
MCP調べてみました! / Exploring MCP
uhzz
2
2.1k
S3静的ホスティング+Next.js静的エクスポート で格安webアプリ構築
iharuoru
0
220
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Gamification - CAS2011
davidbonilla
81
5.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
39
7.2k
Testing 201, or: Great Expectations
jmmastey
42
7.4k
Side Projects
sachag
452
42k
Become a Pro
speakerdeck
PRO
27
5.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
Typedesign – Prime Four
hannesfritz
41
2.6k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
How to train your dragon (web standard)
notwaldorf
91
6k
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