アカウント発行システムを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. 多い分岐・点在するコピペ処理
9. None
10. None

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の処理がほぼ一緒でちょっとだけ違う ... • テスト ◦ 既存機能のデグレが怖い
20. None

21. DDDだったら • （ほぼ）１クラス追加するだけ

22. アプリケーション層は変更なし！ 具体的にどうやってアカウントを発行するか はドメイン層に移譲しているため 変更点はなし 具体的にどうやってアカウントを発行するか の処理はドメイン層に移譲しているため 変更点はなし

23. None

24. おわりに • DDDでもっと楽できるはず！ ◦ ”やること”を決めて”やり方”をビジネスの変化に伴って変えられる 設計 • サービスへのDDD適用は難しいかもしれないけれど、アカウント発行シ ステムなら手が出せそうかも！

25. ご清聴ありがとうございました