アカウント発行システムをDDDでリファクタリングしたら 幸せになりそうな予感がした

Transcript

1. アカウント発行システムをDDDで リファクタリングしたら 幸せになりそうな予感がした @soachr (そーく) 設計・モデリング LT会 2020/12/23
2. @soachr(そーく)
3. 今日話すこと
4. DDDのよさ is 仕様変更が圧倒的楽
5. 社内の読書会で ドメイン駆動設計(DDD) と出会う https://booth.pm/ja/items/1835632
6. DDDやりたい
7. 立ちはだかる壁
8. 1. 10年以上ご愛顧いただいているサービスだからこそ発生する a. 追加仕様によるプログラムの肥大化&複雑化 b. 複雑すぎて誰も手が出せないプログラム 2. トランザクショナルなプログラム a. ビジネスロジックとデータ永続化が混在 b. 多い分岐・点在するコピペ処理
11. サービスに対してDDDは難しい けど...
12. サブシステムの アカウント発行システムなら 規模も小さい
13. アカウント発行システムを DDDでRe:モデリングしてみた
14. 前提：アカウント発行システム • BtoB向けクラウドサービスのアカウント発行システムを想定 • アカウント発行時に契約したプラン・オプションを選択する 機能／プラン Premium Standard 機能A ◦ ◦ 機能B ◦ ◦ 機能C ◦ - 機能D ※オプション ※オプション
15. アプリケーション層 =なにをするか(What)
16. ドメイン層 =どうやって実現するか (How) 機能／プラン Premium Standard 機能A ◦ ◦ 機能B ◦ ◦ 機能C ◦ - 機能D ※オプション ※オプション
17. DDDのよさ is 仕様変更が圧倒的楽
18. 例：新しいプランを増設することになった 機能／プラン Premium Standard Lite 機能A ◦ ◦ ◦ 機能B ◦ ◦ - 機能C ◦ - - 機能D ※オプション ※オプション ※オプション
19. DDDじゃなかったら (トランザクショナルなら) • 設計・実装 ◦ 既存仕様理解＆影響調査が大変 ▪ 大量にあるif分岐 ▪ 同じ変数による条件分岐が色々な場所に点在している ... ▪ ifとelseの処理がほぼ一緒でちょっとだけ違う ... • テスト ◦ 既存機能のデグレが怖い
21. DDDだったら • （ほぼ）１クラス追加するだけ
22. アプリケーション層は変更なし！ 具体的にどうやってアカウントを発行するか はドメイン層に移譲しているため 変更点はなし 具体的にどうやってアカウントを発行するか の処理はドメイン層に移譲しているため 変更点はなし
24. おわりに • DDDでもっと楽できるはず！ ◦ ”やること”を決めて”やり方”をビジネスの変化に伴って変えられる 設計 • サービスへのDDD適用は難しいかもしれないけれど、アカウント発行シ ステムなら手が出せそうかも！
25. ご清聴ありがとうございました