Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
アカウント発行システムをDDDでリファクタリングしたら 幸せになりそうな予感がした
sorch
December 23, 2020
Technology
1
240
アカウント発行システムをDDDでリファクタリングしたら 幸せになりそうな予感がした
sorch
December 23, 2020
Tweet
Share
More Decks by sorch
See All by sorch
おさらい!PHP8で廃止される機能
soachr
1
380
元Javaエンジニアが怖いと思うPHPの仕様
soachr
0
180
Other Decks in Technology
See All in Technology
Hasuraの本番運用に向けて
nori3tsu
0
260
JAWS-UG朝会_41_NakagawaAkihiro.pptx.pdf
anakagawa
2
610
EMになって最初の失敗談 - コミュニケーション編 -
fukuiretu
1
330
20230123_FinJAWS
takuyay0ne
0
100
AI Services 概要 / AI Services overview
oracle4engineer
PRO
0
160
創業1年目のスタートアップでAWSコストを抑えるために取り組んでいること / How to Keep AWS Costs Down at a Startup
yuj1osm
3
1k
証明書って何だっけ? 〜AWSの中間CA移行に備える〜
minorun365
3
2k
2023年は何する宣言
shigeruoda
0
230
ついに来る!TypeScript5.0の新機能
uhyo
16
8.7k
小さなお葬式をAWSに移行したお話
moriryouta
2
150
Startup Studio Sereal / Culture Deck
sereal
0
600
AKIBA.SaaS資料
yasumuusan
0
160
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
21
3.4k
Designing Experiences People Love
moore
130
22k
What’s in a name? Adding method to the madness
productmarketing
12
1.9k
Keith and Marios Guide to Fast Websites
keithpitt
407
21k
It's Worth the Effort
3n
177
26k
The Web Native Designer (August 2011)
paulrobertlloyd
76
2.2k
Building Adaptive Systems
keathley
27
1.3k
Building Flexible Design Systems
yeseniaperezcruz
314
35k
Product Roadmaps are Hard
iamctodd
38
7.7k
A Modern Web Designer's Workflow
chriscoyier
690
180k
Adopting Sorbet at Scale
ufuk
65
7.8k
Designing for humans not robots
tammielis
245
24k
Transcript
アカウント発行システムをDDDで リファクタリングしたら 幸せになりそうな予感がした @soachr (そーく) 設計・モデリング LT会 2020/12/23
@soachr(そーく)
今日話すこと
DDDのよさ is 仕様変更が圧倒的楽
社内の読書会で ドメイン駆動設計(DDD) と出会う https://booth.pm/ja/items/1835632
DDDやりたい
立ちはだかる壁
1. 10年以上ご愛顧いただいているサービスだからこそ発生する a. 追加仕様によるプログラムの肥大化&複雑化 b. 複雑すぎて誰も手が出せないプログラム 2. トランザクショナルなプログラム a. ビジネスロジックとデータ永続化が混在
b. 多い分岐・点在するコピペ処理
None
None
サービスに対してDDDは難しい けど...
サブシステムの アカウント発行システムなら 規模も小さい
アカウント発行システムを DDDでRe:モデリングしてみた
前提:アカウント発行システム • BtoB向けクラウドサービスのアカウント発行システムを想定 • アカウント発行時に契約したプラン・オプションを選択する 機能/プラン Premium Standard 機能A ◦
◦ 機能B ◦ ◦ 機能C ◦ - 機能D ※オプション ※オプション
アプリケーション層 =なにをするか(What)
ドメイン層 =どうやって実現するか (How) 機能/プラン Premium Standard 機能A ◦ ◦ 機能B
◦ ◦ 機能C ◦ - 機能D ※オプション ※オプション
DDDのよさ is 仕様変更が圧倒的楽
例:新しいプランを増設することになった 機能/プラン Premium Standard Lite 機能A ◦ ◦ ◦ 機能B
◦ ◦ - 機能C ◦ - - 機能D ※オプション ※オプション ※オプション
DDDじゃなかったら (トランザクショナルなら) • 設計・実装 ◦ 既存仕様理解&影響調査が大変 ▪ 大量にあるif分岐 ▪ 同じ変数による条件分岐が色々な場所に点在している
... ▪ ifとelseの処理がほぼ一緒でちょっとだけ違う ... • テスト ◦ 既存機能のデグレが怖い
None
DDDだったら • (ほぼ)1クラス追加するだけ
アプリケーション層は変更なし! 具体的にどうやってアカウントを発行するか はドメイン層に移譲しているため 変更点はなし 具体的にどうやってアカウントを発行するか の処理はドメイン層に移譲しているため 変更点はなし
None
おわりに • DDDでもっと楽できるはず! ◦ ”やること”を決めて”やり方”をビジネスの変化に伴って変えられる 設計 • サービスへのDDD適用は難しいかもしれないけれど、アカウント発行シ ステムなら手が出せそうかも!
ご清聴ありがとうございました