Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

5825781c988a48130bb0db577f5c0e09?s=47 sorch
December 23, 2020

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

5825781c988a48130bb0db577f5c0e09?s=128

sorch

December 23, 2020
Tweet

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だったら • (ほぼ)1クラス追加するだけ

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

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

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