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
実録!LOHACOにおけるDDDとCleanなArchitecture/DDD and Cle...
Search
ASKUL Engineer
May 11, 2019
Technology
18
8.8k
実録!LOHACOにおけるDDDとCleanなArchitecture/DDD and Clean Architecture at LOHACO
レガシーをぶっつぶせ。現場でDDD!の資料になります。
https://genbade-ddd.connpass.com/event/127494/
ASKUL Engineer
May 11, 2019
Tweet
Share
More Decks by ASKUL Engineer
See All by ASKUL Engineer
EditorConfigで導くコードの「美しさ」
askul
0
530
いまさら聞けないAWS
askul
0
4.9k
CTOが語る、テックカンパニーに向けた未来の話。by アスクル
askul
0
140
チームでリーダブルコードを実現するには?
askul
0
2.7k
ラズパイを使ってスマートリモコンを作ってみた
askul
0
680
Discord Bot はじめの一歩
askul
0
550
10分で「エラスティックリーダーシップ」をアウトプット
askul
0
2.8k
1on1をする上で大切なこと
askul
1
660
JBUG東京#20 〜そこが知りたい!Backlog活用術〜
askul
1
2.7k
Other Decks in Technology
See All in Technology
AWS re:Inventを徹底的に楽しむためのTips / Tips for thoroughly enjoying AWS re:Invent
yuj1osm
1
570
プロポーザルのつくり方 〜個人技編〜 / How to come up with proposals
ohbarye
1
110
バクラクにおける可観測性向上の取り組み
yuu26
3
420
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
フルカイテン株式会社 採用資料
fullkaiten
0
36k
Commitment vs Harrisonism - Keynote for Scrum Niseko 2024
miholovesq
6
1.1k
グローバル展開を見据えたサービスにおける機械翻訳プラクティス / dp-ai-translating
cyberagentdevelopers
PRO
1
150
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
120
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
210
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
180
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
290k
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
290
What's new in Ruby 2.0
geeforr
342
31k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
How STYLIGHT went responsive
nonsquared
95
5.2k
Building Better People: How to give real-time feedback that sticks.
wjessup
363
19k
Transcript
実録! LOHACOにおける DDDとCleanな Architecture 2019.5.11 レガシーをぶっつぶせ。現場でDDD! アスクル株式会社
自己紹介
さとうだいすけ @dskst9 アスクル株式会社 エンジニアリングマネージャー エンジニアリングマネージャーって楽しいよというのを世の 中に広めたい DDDはエンジニアの必修科目ではないかと最近思う
なかむらとしゆき アスクル株式会社 LOHACOのフロントエンド(寄り)なエンジニア Kotlin + TypeScriptを嗜んでます DDD/Clean Architectureをコツコツ学習中
今日お話すること • レガシーシステム刷新で ◦ DDDを実践した話 ◦ Clean Architectureを導入した話
LOHACO 「LOHACO」の由来は、Lots of Happy Communities “くらしをかるくする”をコンセプトに、暮らしを潤すこだわりの商品を、いつでもリーズナブ ルかつスピーディーにお届けする日用品ショッピングサイト
LOHACOの開発歴史 • 2012年にサービス開始 • 7年+αの歴史がある ◦ 巨大なモノリシックシステム ◦ 肥大化したデータベース ◦
複雑化する仕様
歴史は遺産となる
• ストラングラー・アプリケーショ ン・パターンで ◦ サービス分割してモノリスか ら脱却 ◦ 小さいサービスからモダンに する レガシーからの緩やかな変革
【最古】 モノリシック サーバ LOHACOのシステム構成変革
API群 【最古】 モノリシック サーバ フロントサーバ (WEB) LOHACOのシステム構成変革
【少し古め】 API群 【最古】 モノリシック サーバ 【現役】 フロントサーバ (WEB) 【新】 API群
【新】 カゴレジ フロントサーバ(WEB) LOHACOのシステム構成変革
どの世代でも悩みは同じ • LOHACOのドメインは複雑 ◦ 在庫モデル + マーケットプレイスモデル + 細かな配送日時・エリア +
生鮮販売 + 注文後精米 … などなど • 今後も機能追加・改善は続く • なんとか開発速度・DXを保ちたい
複雑なのはドメインそのもの、 すなわち、ユーザの活動やビ ジネスなのである。ドメインの 持つこの複雑さが設計で扱わ れないのであれば、基盤となる 技術が適切に考えられていた としても意味がない。 引用元 Eric Evans.
エリック・エヴァンスのドメイン駆動設計 (Kindle の位置No.260-261). Kindle 版.
複雑さと戦う
複雑さへの戦略と戦術 • 戦略 ◦ 複雑さをコントローラブルにする • 戦術 ◦ ドメインモデリングを行う
複雑さと戦う DDD
その前に… DDDが難解
複雑さへの戦略と戦術 • 戦術 ◦ ドメインモデリングを行う ▪ 貧弱なドメインモデルを許容し、軽量 DDDからDDDを理解 ▪ ファーストステップは小さなサービスで
実践
【少し古め】 API群 【最古】 モノリシック サーバ フロントサーバ (WEB) 【新】 API群 【新】
カゴレジ フロントサーバ(WEB) 小さくDDDを始めてる半ば この辺の お話
ドメイン分析 - 例 引用元 ヴァーン・ヴァーノン. 実践ドメイン駆動設計 (Japanese Edition) (Kindle の位置No.1721).
Kindle 版.
ドメイン分析 - 例 引用元 ヴァーン・ヴァーノン. 実践ドメイン駆動設計 (Japanese Edition) (Kindle の位置No.1857-1858).
Kindle 版.
ドメイン分析 注文サブドメイン 商品サブドメイン 配送サブドメイン 在庫サブドメイン ユーザサブドメイン 受注サブドメイン
ユビキタス言語 • ユビキタス言語の辞書を作った • 次第に各サブドメインの中に閉じていった ◦ 会話の中に生きている ◦ ユビキタス言語を育てているとは言えない 境界づけられたコンテキストの統合で
問題が起こったのは後のお話
コンテキストマップ • サブドメインから境界づけられたコンテキストを定義 • コンテキストマップをつくりサービス分割を行った ◦ 注文 ◦ 配送 ◦
商品 ◦ ユーザー
コンテキストマップから サービス分割
境界づけられた コンテキストの統合 • 境界づけられたコンテキストの統合は RESTful リソースを 使用 ◦ ドメイン知識をどこまで公開するべきか悩む ◦
ユビキタス言語のブレに悩む ◦ コンテキストの統合というより、コンテキストの密結合、 あるいは一つのコンテキストになった?
ドメイン分析 EC LOHACO 注文サブドメイン 商品サブドメイン 配送サブドメイン 在庫サブドメイン ユーザサブドメイン 受注サブドメイン
探索は 終わらない
引用元 https://domainlanguage.com/ddd/whirlpool/ ストーリーを語 りドメインに フォーカスして モデルを提示 探求して 間違え テストコードを 起こし洗練探求
して 間違え
DDDプラクティスとの付き合い 実践 課題 エンティティ 一意な識別子がないなど 値オブジェクト 集約 ❌ 集約の境界の見定めなど リポジトリ
レガシーDBの相性など アプリケーション サービス Commandパターンと融合
レガシーな現場で 軽量DDDから得た教訓 • レガシーDBに引きずられるな、腐敗防止層はマスト • データモデリングを受け入れるな • ユビキタス言語を育てないと後で泣く • 開発当初からDDDを導入しないと辛い
• 全員がDDDをやるという認識を持つこと ドメインモデル貧血症に要注意!!
DDDファーストステップ所感 1. ドメインモデルの理解が進む、コードが語り始める 2. レガシーDBとはどこまで戦うかが重要 3. 即効性のあるプラクティスはどんな現場でも有効 習うより慣れろ 抽象を理解しても仕方ない DDDはやらないと具体が理解できない
もう少し 具体的なお話
その前に
DDD Clean Architecture 完璧に理解した人
私はというと・・・
とりあえず 本を買いました
引用元URL https://lohaco.jp/ksearch/?searchWord=ドメイン駆動設計
引用元URL https://lohaco.jp/ksearch/?searchWord=実践ドメイン駆動設計
引用元URL https://lohaco.jp/ksearch/?searchWord=現場で役立つシステムシステム設計の原則
引用元URL https://lohaco.jp/ksearch/?searchWord=clean%20architecture
引用元URL https://www.amazon.co.jp/dp/4048930656/
読んだ
なるほどわからん
とはいえ • LOHACOのドメインは複雑 ◦ 在庫モデル + マーケットプレイスモデル + 細かな配送日時・エリア +
生鮮販売 + 注文後精米 … などなど • 今後も機能追加・改善は続く • なんとか開発速度・DXを保ちたい
Cleanな Architecture とDDD を導入
【少し古め】 API群 【最古】 モノリシック サーバ フロントサーバ (WEB) 【新】 API群 【新】
カゴレジ フロントサーバ(WEB) LOHACOのシステム構成 さっきの お話
【少し古め】 API群 【最古】 モノリシック サーバ フロントサーバ (WEB) 【新】 API群 【新】
カゴレジ フロントサーバ(WEB) この辺のお話 この辺の お話
カゴレジフロントサーバ? • LOHACOのカート/決済画面を表示 • 新旧複数のAPIを呼び出す • ビジネスロジックも含む
使用技術 • Kotlin 1.3 • Spring Boot 2.1 • Maven
アーキテクチャ
引用元URL https://dzone.com/articles/onion-architecture-is-interesting ヴァーン・ヴァーノン 実践ドメイン駆動設計 図4-4 引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Onion Architecture Hexagonal
Architecture Clean Architecture 依存は外から内へ
レイヤーを分けた 引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Domain Application Infrastructure Web
Web 依存関係 Domain Infrastructure (API) Application ※ A->BはAはBに依存することを表す
Web 依存関係詳細 Domain Infrastructure (API) Application MVCのController UI表示 Domainを 組み合わせる
ビジネスロジック API call 実装
サンプル コード
引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Domain層 = Entities Domain 層
引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html ※ Clean Architectureに 忠実に則るならPresenter をDIするべきだが・・・ Application層 = Use
Cases Application 層
引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Infrastructure層 = Gateways Infrastructure 層
引用元URL https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Web層 = Web/UI ※右図の Presenter とは違う Web 層
Web 層
チーム開発で Cleanな Architecture を保つために
工夫点1
外から内への 依存関係を厳守するために Maven multi-module 構成に
Maven multi-moduleとは lohaco ├─pom.xml ├─domain/ | ├─src/ | └─pom.xml ├─application/
| ├─src/ | └─pom.xml ├─infrastructure/ | ├─src/ | └─pom.xml └─web/ ├─src/ └─pom.xml プロジェクト内に サブモジュールを定義できる
サブモジュール間の依存関係を制御 domain を使える? application を使える? infrastructure を使える? web を使える? domain
⛔ ⛔ ⛔ application ⛔ ⛔ infrastructure ⛔ web
工夫点2
レイヤ毎に 極力 ライブラリ非依存 にする
『Clean Architecture』 第32章 フレームワークは詳細 「フレームワークとなん か結婚するな」
極力ライブラリ非依存に spring 使える? log4j2 使える? spring-web 使える? junit 使える? domain
⛔ ⛔ ⛔ application ⛔ infrastructure web
注: Clean Architectureと 異なる点
命名が違う • Gateway -> Repositoryなど • DDDに寄せた • DDD寄りな命名の方が多くの開発メン バーが馴染みがあるだろうと判断
本家の流儀から外れている • Application層からWeb層にDomain層の オブジェクトを返却 ◦ 本家はPresenterでDIするイメージ • 疎結合で得られるメリットと実装面・学習 面のコストを考慮して判断
Presenter • Domain層のオブジェクトをUI向けに変換 する役割としてWeb層に定義 • 実現したい役割はClean Architectureで 定義されているクラスと同じだったので名 前を流用
で、どうだった?
開発してみての感触 • 依存関係の違反をコンパイラが怒ってくれ るのがありがたい ◦ 新規メンバーが間違えにくい ◦ コードレビューが楽 • それぞれのレイヤのユニットテストも書ける
(あまり書けてない)
失敗した点
依存関係ざっくり問題 • Web層 -> Infrastructure層 への依存を許したことで ◦ Web層におくべきものが Infrastructure層に置かれて ソースがカオス
◦ Web層からRepository実装 を呼べてしまう Web(UI) Infrastructure (API) Application この依存は 失敗
ペリフェリックアンチパターン 引用元URL https://ja.wikipedia.org/wiki/%E3%83%9A%E3%83%AA%E3%83%95%E3 %82%A7%E3%83%AA%E3%83%83%E3%82%AF フランスの環 状道路 Infrastructure Web Domain Application
ヴァーン・ヴァーノン 実践ドメイン駆動設計 図4-4 Hexagonal Architecture サブモジュールを細かく するべきだった? • Hexagonal Architectureでいうと
ころのアダプター単位くらいで良 かったかも • アダプター間の依存関係は当然持 たせないようにする
ところで DDDは?
None
即効性の ありそうな プラクティスは 取り入れている
Value Object • 増田さんの提唱する型指向プログラミング ◦ 言語が提供するそのままの型(String/Int)を極力使わ ない ◦ 値の種類毎に ▪
独自のクラスを定義 ▪ 有効な値の範囲を定義 ▪ 判定・計算ロジックをもたせる
Value Objectの例 ※注 LOHACOは0円 サンプル商品がある
腐敗防止層 • レガシーなAPIにドメイン層が引きずられないように ◦ レガシーなクラス -> ドメイン層用クラスに変換 ◦ 変換はレガシー具合にもよるが大変
腐敗防止層の例 APIのレスポンスと Domain層のオブ ジェクトをマッピング させる
まとめ • LOHACOではDDD/Clean Architectureを絶 賛導入中 • DDD/Clean Architectureはレガシーなシス テムと上手く付き合う武器となる
まとめ アスクルでは 一緒にDDD/Clean Architectureを 推進してくれるエンジニアを 絶賛募集中!!
告知 アスクル初の技術カンファレンスを開催します! https://askul.connpass.com/event/125471/
レガシーは 明日から モダンにはならない
ご静聴 ありがとうございました