Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
DDDお悩み相談事例 シーズン1
かとじゅん
September 06, 2019
Programming
3
960
DDDお悩み相談事例 シーズン1
かとじゅん
September 06, 2019
Tweet
Share
More Decks by かとじゅん
See All by かとじゅん
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
j5ik2o
2
810
EIPとAkkaについて
j5ik2o
3
1.5k
モデルを中心にデザイン(設計)すること
j5ik2o
2
980
ドメインイベントの観点から再考するソフトウェア設計
j5ik2o
16
7.1k
セキュリティのためのソフトウェア設計について
j5ik2o
3
1.5k
AWS Dev Day 2021 - AWSでスケーラビリティとレジリエンスを実現するアーキテクチャを考える
j5ik2o
2
1.3k
AWSでCQRS Event Sourcing するにはどうすればいいのか
j5ik2o
10
3.3k
ChatworkDevDay_リアクティブシステムと次世代基盤について_加藤
j5ik2o
2
1.1k
リアクティブシステムとCQRS/ESで実現する Chatwork新アーキテクチャについて
j5ik2o
7
2k
Other Decks in Programming
See All in Programming
フロントエンドで学んだことをデータ分析で使ってみた話
daichi_igarashi
0
180
Writing Greener Java Applications
hollycummins
0
340
[2023년 1월 세미나] 데이터 분석가 되면 어떤 일을 하나요?
datarian
0
590
Cloudflare Workersと状態管理
chimame
3
480
新卒でサービス立ち上げから Hasuraを使って3年経った振り返り
yutorin
0
220
Spring BootとKubernetesで実現する今どきのDevOps入門
xblood
0
340
Swift Expression Macros: a practical introduction
kishikawakatsumi
2
720
10年以上続くプロダクトの フロントエンド刷新プロジェクトのふりかえり
yotahada3
2
330
SHOWROOMの分析目的を意識した伝え方・コミュニケーション
hatapu
0
240
Ruby Pattern Matching
bkuhlmann
0
610
ちょうぜつ改め21世紀ふつうのソフトウェア設計
tanakahisateru
7
6.4k
Circuit⚡
monaapk
0
200
Featured
See All Featured
Practical Orchestrator
shlominoach
178
8.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
346
17k
GraphQLとの向き合い方2022年版
quramy
20
9.9k
Support Driven Design
roundedbygravity
88
8.9k
Six Lessons from altMBA
skipperchong
15
2.3k
How To Stay Up To Date on Web Technology
chriscoyier
779
250k
Testing 201, or: Great Expectations
jmmastey
25
5.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
351
21k
For a Future-Friendly Web
brad_frost
166
7.8k
Into the Great Unknown - MozCon
thekraken
2
290
Documentation Writing (for coders)
carmenintech
51
2.9k
jQuery: Nuts, Bolts and Bling
dougneiner
57
6.6k
Transcript
DDDお悩み相談事例 シーズン1 かとじゅん(@j5ik2o)
作る対象やその規模にかかわらず、DDDは有用か? • 有用。一般的には何らかの問題を 解決するのがシステムの目的。ゆえ にドメインが存在しないシステムは ありえないと考えて差し支えない。 • ただし、業務システムに対するプレ ゼンテーションの役割を果たすシス テムでは、CRUDが主目的になるこ
とがある 帳票システム 業務システム 業務の結果をCRUDする Command Query ドメイン リードモデル イベント
フロントエンドはDDDと関係ないのでは? • ビジネスロジックがサーバサイドだけにある なら、フロントエンドは完全なユーザインター フェイス層。しかし、クライアントサイドにもド メインロジックはありえる • たとえば、オークションサイトなら出品物の 落札期限が文字列表現としてREST APIな
どのレスポンスで返ってくるので、クライアン トはそのまま表示します。しかし落札までの 残り時間はクライアントで計算しなければな りません 出品ドメイン オブジェクト 出品DTO 落札期限 出品ビュー 出品ドメイン オブジェクト 落札残り時間 クライアント サーバ
DDDに共通の課題感があってそれを乗り越えた方法の 一つがCQRSだったのか? • GregさんがCQRS and Event Sourcingのアイ デアを公表したのが2010年ぐらい。コミュニティ でも盛り上がったのは2011年。 •
Chatworkでは2016年末にKafka, HBase, Akkaを使ってEvent Sourcingシステムをリリー スしている。 • Akkaでは分散システム上でEvent Sourcingを 実装する手段を提供している ◦ akka-persistence ◦ akka-cluster-sharding • event store(https://eventstore.org/) が選択 肢のひとつ
レガシーシステムへのDDD導入方法は? • 「コアドメインの中で仕事をする」・「ユビキタス言語を作って使う」・「モデルを実装に 反映する」の三本柱。どれが掛けてもよくない。局所的でも三本柱を立てる。例え ば、リファクタリングなら、ユニットに閉じて三本柱を立てる • レガシーシステムの改善にはDDD以外の考え方が必要。「レガシーシステム改善 ガイド」読みましょう。改善の道はリファクタリング→リアーキティング→リライトの階 段を登る。いきなりリライトではない •
実装のミクロな視点でいえば、データとロジックを統合して値オブジェクト化を進め る。数量はただのIntではない。電話番号はただのStringではない。ビジネスルー ルに基づく計算能力を持つオブジェクトという前提に立つ
売上リポジトリ DAOとリポジトリの違いは? • DAOはDBのテーブルの行をI/O する責務。リポジトリは生成済み の集約の参照を取得したり削除す るための責務。 • 集約とテーブルが一対一対応して いても責務としては異なる。集約
はどんな永続化技術からも中立 • ビジネスロジックに入出力に関係 する知識を含めない。責務重複の 回避 売上集約 売上エンティティ 売上詳細 ローカルエンティティ 売上DAO 売上レコード 売上詳細レコード 売上詳細DAO 永続化責務から解放さ れなければならない
おしまい