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

© DMM © DMM 破壊せよ！データ破壊駆動で考えるドメインモデリング 2024/10/25(金) 合同会社DMM.com プラットフォーム開発本部
ミノ駆動

© DMM 自己紹介ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部第3開発部
DeveloperProductivityGroup DMMプラットフォームの設計を改善し開発生産性向上を図るのがミッション 2

© DMM もうちょっと具体的な仕事の内訳サービス全体で共通利用されるDMMプラットフォーム（アカウント管理、不正対策、決済、DMMポイント etc..）の設計品質改善 • 設計ガイドライン策定 • チームへの設計指導
• プラットフォーム所属のエンジニア（約120人！）に対する設計勉強会ミノ駆動本を使ったワークショップ形式の実践講習 • リファクタリング体制整備 3

© DMM マイナス注文数と返金注文画面で注文数に「-1」を入力し注文実行したところ、異常を知らせるような表示もなく、すんなり注文できてしまった。後日経理の人がすっ飛んで来て、「注文した人に返金するよう返金指示書が発行された。その人は今いるか」といった奇妙なことが発生。注文した人に返金！？
もうヤバいですねこれ。 10 総額：　＄-39 注文数： -1 カートに入れる今すぐ購入

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

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

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

© DMM 問題解決に必要な設計 1. データ完全性を保証する設計 2. （完全性保証用の）バリデーションがバラバラに実装されるのを防ぐ設計この2つを同時に設計できるとても良い設計があります。それが……
21

© DMM データ破壊駆動クラッカーになったつもりで以下を検討します。 • どうやったらクラス内のデータ（インスタンス変数）を破壊できるか • どうやったら矛盾したデータを作れるか •
どうやったらユーザーが困る状況に陥るかこの検討をすることで、正常な値を保証する、即ち完全性を保証する制約が洗い出されます。 25 Let’s 破壊駆動！！

© DMM 26 // 金額クラス public class Money { public
int amount; public Currency currency; } Moneyクラスのインスタンス変数を破壊してみよう

int amount; public Currency currency; } • amount(金額値)をマイナスにできてしまう • 別の金額にすり替えることができてしまう • currency(通貨単位)がnullはありえない • 途中で別の通貨単位に変更されるのは問題

int amount; public Currency currency; } 【制約】 • amountは0以上 • amountは不変【制約】 • currencyは非null • currencyは不変

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

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

© 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クラス単体でデータ完全性を保証できるようにする

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

© DMM 35 class CommonManager { int addMoneyAmount(Money money1, Money
money2) { return money1.amount + money2.amount; } } 金額加算ロジックがMoneyとは全然関係ない箇所に実装されている。金額関係のロジックがどこに実装されているのか把握が難しくなり、変更容易性が低下する。

© 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クラスにカプセル化する。これでドメインモデルの完全性が満たされる。ドメインモデルの完全性を満たすことで変更容易性が向上する

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

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

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

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

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

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

More Decks by MinoDriven

Other Decks in Programming

Featured

Transcript