破壊せよ！データ破壊駆動で考えるドメインモデリング / data-destroy-driven

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© DMM 注文総額を好きなように減額する裏技このマイナス注文数による返金があったか調査したが見当たらなかった。しかし別の不正が大量にあったことが発覚。注文の際、買い物カゴの中に欲しい商品と一緒に、マイナス注文数の商品を入れることで注文総額を減額する、という裏技だった。この手口は噂として広まっていて、かなりの不正が発生していた…… 11 総額：＄207 価格：＄246 注文数：1 価格：＄39 注文数：-1

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© DMM 壊れたデータによるバグバグの原因はさまざま。その中でも、不正なデータ、壊れたデータによるバグが多くを占めます。 ● 外部から不正な値を入力される ● ロジックが正しくないために、壊れたデータが内部的に作られてしまうだから本日はセキュリティの話ではありません。データ全般の異常系に関する設計の話なのです。また、壊れたデータがDBに保存されてしまうことがマズいので、POSTや PATCHといった更新系リクエストを対象とします。参照系は対象外です。 14

Slide 15

Slide 15 text

© DMM 異常系は後手に回りがちこういうの多くないですか？身に覚えはありませんか？ ● とにかく動くものを早く作る。 ● データが壊れるようなバグが出たら付け焼き刃的にバリデーションを実装。 ● そのバリデーションもUtilなどいい加減な箇所に五月雨に実装。 ● バリデーションの呼び忘れで同じバグが発生することも。機能開発時、正常系のことばかり考えてしまい、異常系がおざなりになったり、後手に回ることが多くはありませんか？ 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© DMM 29 class Money { int amount; Currency currency; } class Validator { static boolean validateMoneyAmount(Money money) { return 0 <= money.amount; } } ダメなのはこういう構造。せっかく制約を洗い出せても、これではMoneyクラス単体で完全性を保証できない！壊れたデータが入り込む余地がある！大した根拠もなく「バリデーションは別に実装するものだ」と固く信じている人が一部にいるので注意。ダメ絶対

Slide 30

Slide 30 text

© DMM 30 カプセル化カプセル化とは、データとそのデータを操作するロジックをひとつにまとめること。クラスはカプセル化の手段のひとつ。（golangでは構造体、Reactではコンポーネント）「クラスって何のためにあるの？」と聞かれたら「カプセル化のためです！！」と即答できるようになりましょう。クラスでのカプセル化とは、インスタンス変数とそのインスタンス変数を操作するロジックをひとまとめにすること。クラス自身で（←ココ大事）完全性を保証できるよう、そのクラスに関連ロジックをカプセル化しよう。

Slide 31

Slide 31 text

© DMM 31 // 金額クラス class Money { final int amount; final Currency currency; Money(final int amount, final Currency currency) { if (amount < 0) throw new IllegalArgumentException(); if (currency == null) throw new IllegalArgumentException(); this.amount = amount; this.currency = currency; } } finalを付与し不変に完全コンストラクタ。インスタンス生成時に値チェックし、初期化。 Moneyクラス単体でデータ完全性を保証できるようにする

Slide 32

Slide 32 text

© DMM テストコードもデータ破壊駆動で！ 32 @Test void testNegativeAmountThrowsException() { assertThrows(IllegalArgumentException.class, () -> { new Money(-1, Currency.getInstance(Locale.JAPAN)); }); } 境界値テスト。異常値を入れて例外がスローされることを検証する。

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© DMM // 金額クラス class Money { (中略) Money add(final Money other) { if (!currency.equals(other.currency)) { throw new IllegalArgumentException(); } final int added = amount + other.amount; return new Money(added, currency); } } 38 金額加算メソッドもMoneyクラスにカプセル化する。これでドメインモデルの完全性が満たされる。ドメインモデルの完全性を満たすことで変更容易性が向上する

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© DMM 40 メール設定メール設定ID ユーザーアカウントID プライマリメールアドレスID メールアドレスメールアドレスID アドレス文字列 * GitHubっぽいメール設定のモデル。複数メールアドレスを追加できる。どれか1つをプライマリに設定できる。この手のドメインモデリングではデータだけが洗い出されがち。もっと大事なのは制約！！データ破壊駆動で制約を洗い出してみよう。ドメインモデルの完全性の観点でモデルに必要な機能を洗い出してみよう。

Slide 41

Slide 41 text

© DMM 41 メール設定メール設定ID ユーザーアカウントID プライマリメールアドレスID メールアドレスメールアドレスID アドレス文字列 1..* (null)も含め不正なIDだと困るフォーマットに従っていないアドレスだと困る IDやアドレスを変更されると困る (nullも含め)不正なIDだと困るメール設定IDやユーザーアカウントIDを変更されると困るプライマリメールアドレスに他人のアドレスIDを設定されると困るメールアドレスの追加、削除ができる必要があるメールアドレスを全部削除されると困るプライマリメールアドレスを削除されると困る同じメールアドレスを追加されると困るデータ破壊駆動で考えるだけでこれだけの制約が洗い出される

Slide 42

Slide 42 text

© DMM 42 弊社DMMでデータ破壊駆動をやってみたとあるチームの新規機能開発で、ミノ駆動が設計支援に入りました。設計フェーズでドメインモデリングを実施し、そこでデータ破壊駆動をやってみました。本スライドにあるように「クラッカーになったつもりで、どうやったらモデルのデータを壊せるか、矛盾したデータにできるかを考えてみましょう」と指示。すると、以降ミノ駆動があれこれ何も言わなくてもチームメンバー同士が自律的にどうやったら壊せるかを議論し始め、あっという間に制約を洗い出すことができました。そして頑強なコードを実装できました。効果てきめんです！！

Slide 43

Slide 43 text

© DMM まとめ ● バグは、データ異常が原因のものが多くを占める。しかし異常系の検討は後手に回りがち。 ● データ破壊駆動で「どうやったらデータ（インスタンス変数）を破壊できるか」を考えてみよう。破壊されないための制約を洗い出そう。 ● クラス自身で完全性を保証できるように制約をカプセル化しよう。 ● ドメインモデル完全性の観点から、必要なドメインロジックをカプセル化し、変更容易性を高めよう。 ● ドメインモデリングの段階からデータ破壊駆動で設計しよう。 43