ちょっと休憩：『ハムレット』の悲劇｜セキュア・バイ・デザイン２章を読んで印象に残ったところと自分自身の振り返りまとめました

はじめに

セキュア・バイ・デザイン第２章『ハムレット』の悲劇について、

個人的に印象に残ったところと、それに対する感想や自分自身の振り返りなどをまとめてみました。

ハムレットの悲劇のお話

冊数マイナスで購入できる欠陥を抱えたオンライン書店を数ヶ月間運用した。

ある日脆弱性診断でそれが発覚し、技術的な対処すぐ行った。

しかし、、、

ユーザが実際に買う本と冊数マイナスの本をセット購入して割引の裏技情報がでまわってしまい大きな損害が出たが、

それらを行ったユーザはオンライン書店を頻繁に利用するユーザなので請求などはできなかった。

と言う、実話を少し変えたお話がこの章のお題でした。

なぜ浅いモデリングになるのか？？深いモデリングにするにはどうすれば良いか？？

そもそもモデリングの際、

「本」は「価格」と「ISBN」を持つ、「注文」は「注文明細」を持ち、注文明細には「本」と「冊数」を持つ

と言うように明示的に専用のBook型やOrder型などで表現する一方、

「価格」や「冊数」については暗黙的にint型(-20億〜20億の間の整数を取りうるなど)で表現したりされることが多い。

このように浅いモデリングになってしまうのは、

ドメインエキスパートにヒアリングする際、

この概念はコードでどう表現するか？？と言う観点で話を聞いているのが原因で、

深いモデリングにするためには、

この概念はこのドメインでどのように機能するのか？？この概念をどうすれば理解できるか？？

と言う観点で聞く必要があるよ。

というようなことが述べられていました。

確かに、自分もヒアリングしながらこんなテーブルにこんな感じでデータ持たせて、

こういう共通機能作って・・・これくらいの工数かかりますね！！みたいなことしか考えてないなぁと

改めて反省しました。。。

自分の場合も冊数と聞いただけで確実にintに決めつけて表現して、それ以上の深堀はしなかったと思います。

せめてヒアリングで出てきた冊数のような概念も最大値、最小値くらいはまず確認していくところから改善が必要かな、、、

すべての概念を明示的に型で表現するとクラスが膨大になるという反対意見

「価格」や「冊数」などドメインエキスパートのヒアリングで出てくる概念を

すべて明示的に型で表現するとクラスが膨大になる！！という反対意見に対して、

本では、

結局ビジネスロジックはどこかしらで表現することになる。

それが、サービスクラスの、サービスメソッドの至る所に同じような処理書くくらいなら、

明示的に概念を表現して１箇所にビジネスロジックを書く方がいいじゃん。

というようなことが述べられていました。

おっしゃる通りです、、、、

僕もなんでもかんでも値オブジェクトガチャガチャ作り始めるとめちゃくちゃ大変そう。。。

くらいにしか考えられなかった浅い理解の時期もあったのですが、

これを聞いて改めて、

この概念はこのドメインでどのように機能するのか？？この概念をどうすれば理解できるか？？

という観点でヒアリングして重要な概念をそもそも洗い出せているのか？？

それで洗い出した結果重要なら、

結局何処かにその概念を表現する必要があるのだから、

例えば値オブジェクト使って１箇所でわかりやすい箇所に表現した方がいいよね。

という考え方が必要なのだと思いました。

まとめ

個人的には、

セキュア・バイ・デザイン第２章『ハムレット』の悲劇の中では以下２点が印象深かったです。

今日から早速この考え方を取り入れてヒアリングやモデリングをしてみようと思います！！