この記事は ZOZO #3 Advent Calendar 2021 ９日目の記事になります。
これまでドメイン駆動設計に挑戦したい、やりたいけど設計の仕方が変わるため上司を説得できないなどの理由で導入を見送ってきた方々に、今回は１冊本を紹介したいと思います。
これを読むとドメイン駆動設計でないとまずいとまで考えることができる・・・かな。。。少なくても導入のきっかけにはなるかと思います。
その書籍とは「セキュア・バイ・デザイン 安全なソフトウェア設計」になります。
この書籍はドメイン駆動設計をセキュリティ面から捉え直した、、、いや逆ですね。ソフトウェアをセキュリティ面から考慮していったらドメイン駆動設計にたどり着いたという方が正しいかもしれません。
この書籍の大前提として、
「セキュリティを意識しながら開発を進めるのは実際問題困難」という立ち位置からスタートしています。
みなさんのプロジェクトではいつごろからXSS攻撃対策やSQLインジェクション対策などのセキュリティの対応をしてますか？始まる前から？実装中すでに？ほぼ終わってから？
理想は始める前からでしょうが、ほとんどの方は終わる頃に外部の脆弱性診断などを通して対策するのではないでしょうか？
それは、開発者は概してある程度の知識を持っていたとしてもセキュリティの専門家ではないこと、実装中の優先度の面でセキュリティへの対処よりビジネスロジックの実装に力を入れてしまいがちなことが理由としてあげられます。
だったら、セキュリティ的に効果の高い設計を追求することでセキュリティについてそれほど意識せず実装できるようにしようというアプローチがこのセキュアバイ・デザインの趣旨となります。
では、ドメイン駆動設計を実践することでセキュリティ的に効果が高い設計ができるのか？という点が気になるところですが、そこはこの書籍を読むことで、例を踏まえた説明がなされているのでぜひ読んでいただきたいです。
逆にこの本を読むことでこれまでの設計実はまずいのでは？と思うこともしばしばあるかもしれませんね。
2章とか読むと本当に恐ろしい例が載っています。簡単に要約すると、
オンライン書店の例ですが、購入点数をinteger（-2147483648～2147483647）にしたばかりにマイナスの数値が入力できてしまい、合計金額がマイナスになり、しかもこのシステムが経理システムとの連動もしていたため（オンラインストアでマイナスの金額で返金対応というのはよくあること）、買っていないのに返金対応となってしまったというものです。
これってフロント上でセレクトボックスで整数しか選択できなくても、Javascriptでチェックしていても、ブラウザの機能一つでどうにでもできちゃうことがありますよね。
バック側でバリデーションしていないからというのもありますが、返金することがあるとわかっているとバリデーションが漏れてしまうというのも理解できないでもないですね。
これを設計で防ごうとすると、非常に役に立つのはValueObjectになるかと思います。
購入点数をintegerではなくちゃんと「購入点数」として設計することで購入点数という概念を明示的に表現することで、きちんと購入点数の範囲しか扱えないようにする。
その概念を捉えるためにドメインエキスパートを活用する。。。などドメイン駆動設計のエッセンスがすごく役に立つわけです。
さらに言えば、ここは2章には載っていませんが、返金と購入についてはコンテキストが異なるので、それぞれで「購入点数」という概念が異なります。購入コンテキストではマイナスは厳禁だが、返金コンテキストではマイナスがありえるということです。
この辺りもドメイン駆動設計のテクニックが盛り込まれた設計になると思います。
特にドメイン駆動設計導入に躊躇されている方々に読んでみていただきたい1冊ですのでぜひご一読ください。
次の日も自分ですね。明日は「小ネタ：spotlessフォーマッタでEnumが崩れるのを防ぐ設定」というタイトルでお届けします。