Tweet
Tweet

Slide 1

Slide 1 text

アカウント発行システムをDDDで リファクタリングしたら 幸せになりそうな予感がした @soachr (そーく) 設計・モデリング LT会 2020/12/23

Slide 2

Slide 2 text

@soachr(そーく)

Slide 3

Slide 3 text

今日話すこと

Slide 4

Slide 4 text

DDDのよさ is 仕様変更が圧倒的楽

Slide 5

Slide 5 text

社内の読書会で ドメイン駆動設計(DDD) と出会う https://booth.pm/ja/items/1835632

Slide 6

Slide 6 text

DDDやりたい

Slide 7

Slide 7 text

立ちはだかる壁

Slide 8

Slide 8 text

1. 10年以上ご愛顧いただいているサービスだからこそ発生する a. 追加仕様によるプログラムの肥大化&複雑化 b. 複雑すぎて誰も手が出せないプログラム 2. トランザクショナルなプログラム a. ビジネスロジックとデータ永続化が混在 b. 多い分岐・点在するコピペ処理

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

サービスに対してDDDは難しい けど...

Slide 12

Slide 12 text

サブシステムの アカウント発行システムなら 規模も小さい

Slide 13

Slide 13 text

アカウント発行システムを DDDでRe:モデリングしてみた

Slide 14

Slide 14 text

前提：アカウント発行システム ● BtoB向けクラウドサービスのアカウント発行システムを想定 ● アカウント発行時に契約したプラン・オプションを選択する 機能／プラン Premium Standard 機能A ○ ○ 機能B ○ ○ 機能C ○ - 機能D ※オプション ※オプション

Slide 15

Slide 15 text

アプリケーション層 =なにをするか(What)

Slide 16

Slide 16 text

ドメイン層 =どうやって実現するか (How) 機能／プラン Premium Standard 機能A ○ ○ 機能B ○ ○ 機能C ○ - 機能D ※オプション ※オプション

Slide 17

Slide 17 text

DDDのよさ is 仕様変更が圧倒的楽

Slide 18

Slide 18 text

例：新しいプランを増設することになった 機能／プラン Premium Standard Lite 機能A ○ ○ ○ 機能B ○ ○ - 機能C ○ - - 機能D ※オプション ※オプション ※オプション

Slide 19

Slide 19 text

DDDじゃなかったら (トランザクショナルなら) ● 設計・実装 ○ 既存仕様理解＆影響調査が大変 ■ 大量にあるif分岐 ■ 同じ変数による条件分岐が色々な場所に点在している ... ■ ifとelseの処理がほぼ一緒でちょっとだけ違う ... ● テスト ○ 既存機能のデグレが怖い

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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