個人的に印象に残ったところと、それに対する感想や自分自身の振り返りなどをまとめてみました。冊数マイナスで購入できる欠陥を抱えたオンライン書店を数ヶ月間運用した。ある日脆弱性診断でそれが発覚し、技術的な対処すぐ行った。ユーザが実際に買う本と冊数マイナスの本をセット購入して割引の裏技情報がでまわってしまい大きな損害が出たが、それらを行ったユーザはオンライン書店を頻繁に利用するユーザなので請求などはできなかった。言う、実話を少し変えたお話がこの章のお題でした。「価格」や「冊数」については暗黙的にint型(-20億〜20億の間の整数を取りうるなど)で表現したりされることが多い。深いモデリングにするためには、この概念はこのドメインでどのように機能するのか??この概念をどうすれば理解できるか??と言う観点で聞く必要があるよ。いうようなことが述べられていました。確かに、自分もヒアリングしながらこんなテーブルにこんな感じでデータ持たせて、こういう共通機能作って・・・これくらいの工数かかりますね!!みたいなことしか考えてないなぁと改めて反省しました。自分の場合も冊数と聞いただけで確実にintに決めつけて表現して、それ以上の深堀はしなかったと思います。結局ビジネスロジックはどこかしらで表現することになる。明示的に概念を表現して1箇所にビジネスロジックを書く方がいいじゃん。いうようなことが述べられていました。僕もなんでもかんでも値オブジェクトガチャガチャ作り始めるとめちゃくちゃ大変そう。値オブジェクト使って1箇所でわかりやすい箇所に表現した方がいいよね。いう考え方が必要なのだと思いました。まとめ個人的には、セキュア・バイ・デザイン第2章『ハムレット』の悲劇の中では以下2点が印象深かったです。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。