セキュア・バイ・デザイン 第2章 ちょっと休憩：『ハムレット』の悲劇
===
###### tags: `セキュア・バイ・デザイン読書会`

/poll "アンケート第1問！ >>> 『セキュア・バイ・デザイン読書会への参加は何回目？』" "はじめて！" "2回目！" "3回目！" "100回！" "なんかいっぱい！！！"

/poll "アンケート第2問！ >>> この章は難しかった？" "お手上げ" "日本語難しすぎない？" "ちょっと何言ってるか分かんない" "まあ分かる" "余裕でした" "読んでない(小声)" "今読んでいる(小声)" "今読んでいる(大声)"

# Discord開始位置

-

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 第2章 序章
## 目安の時間
- 22分

## 感想・気づき

- 本書でいう「浅いモデリング」と「深いモデリング」とは何を指しているのだろう。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934410470771793980)
- 浅いモデリングは、「その場しのぎのモデリングを深いモデリングに対して、浅いモデリング」（2.2章）と言っている
- 深いモデリングの方の説明は若干、エリック・エヴァンスのドメイン駆動設計に出ているものほどの説明がなさそう？
- [DDD reference](https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf)の8ページには、「表面的なものを脱ぎ捨て、本質的なものを捉えたモデルは、深いモデルです。」とある
- 「表面的なもの」、「本質的なもの」ってわかりずらいですよね。何をもって表面的・本質的っていうのだろうか明確な答えがないですよね。:+1:
- 原文：A model that sloughs off the superficial and captures the essential is a deep model.

- -1冊の本の購入が通ってしまうのもまずいけど、-39ドルの値が入ったら返金扱いになる経理システムもまずいよね
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934407853270245436)
- 支払い、返金は別のAPIにしたいですね。:+1::+1::+1::+1:
- ここを、声上げてくれる人の存在はありがたい(が、これまでそのまま通ってたというのは辛い話になる)
- 2章より後を先に読んでたので、この章はこの後の技術的導入であって、「浅いモデリング」/「深いモデリング」以外は特に議論する内容がないよう(!?)な印象を持ちました。

## 疑問

---

# 2.1 ビジネス／ルールの観点における完全生（integrity）の問題
## 目安の時間
- 22分

## 感想・気づき

- > P.49 セキュリティの観点から見ると、これはセキュリティへの侵害（security breach）です。セキュリティで重要視される要素の1つにデータの完全生があります
- CIA-Tの話が出てきた

- > P.50 銀行からすると、企業がユーザに支払われなければならない金額があることは珍しいことではなく、長いあいだそのような状態が続いていることさえあります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934416978838425630)
- マイナスの請求が出来てしまうのがまずいって思っていたけど、売掛金元帳の世界ではごく当たり前のことだから、システム単体としては間違いではないってのがミソなんだな :+1::+1::+1:

- > P.49 本の注文に対してオンライン書店がそのユーザに対してお金を払うことは、ビジネス・ルールとして正しくありません。つまり、このシステムには、ビジネス的観点において完全性の欠陥があることになるのです。
- 完全性は、情報が変更されないこと。変更できても、許可された方法でのみ変更が可能というもの
- オンライン書店がユーザに対してお金を払うこと（返金）は、返品を受け付けた時のみ。ということだから、上記の例だと許可された方法以外で情報が変更されていることと捉えた:+1:

- > p.54 実はこのような場合は、出荷システムは実行時例外をスローするようになっていて、その例外に関するメッセージがシステム・ログとして残るようになっていました。しかしながらこのエラー・メッセージは大量のその他のメッセージとともにログに出力されてしまっており・・・誰の目にも止まることはありませんでした。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934414299567357992)
- 悲しい
- ログとかエラートラッキングも設計なんだなとしみじみ感じました　:+1: :+1: :+1::+1::+1::+1::+1::+1:
- :memo: ログ設計が残念なのもさることながら、ログをどのように業務で扱うのかという運用設計も残念。 運用設計をしないまま開発されて、動くけど使い続けるのが大変、みたいなシステムはあちこちに……。
- :memo: エラーログも、リファクタしないといけない。

## 疑問
- > P.54 本来であれば、15冊の本を所有し、負債がないことになるのですが、実際には、16冊の本を所有して、1冊分の負債を負っている
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934413054110744617)
- これってどういうこと？
- :memo: 負債とはマイナスの売掛金残高ですね。
- :memo: ユーザから買ったよ、だから一冊在庫増えて発注費は買掛金な感じですかね。

---

# 2.2 浅いモデリング（shallow modeling）
## 目安の時間
- 22分

## 感想・気づき

- わかってはいたけど、在庫の数え方は複雑 :+1: :+1: :+1::+1::+1::+1::+1:

- > P.57 開発者がうまくモデリングできたと最初に思った時点で、それ以上は深く考えたり疑問を抱いたりすることをやめてしまい、さらに、それ以降の計画を立てたり考慮したりすることをやめてしまったからだと考えています
- モデルに完成はなくて、常に成長させ続けるものってどこかでエヴァンス本にも描いてあった気がするな　:+1: :+1::+1:

- > P.57 開発者が陥りやすいのが、対象の概念をどのように表現するのか、ということだけを考えて設計をしてしまうことです。このような考え方をした場合、設計は対象の概念をコードでどのように表現するのかを見つけるためだけの作業となってしまいます。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934422285211795466)
- 多くの開発者がこうなんじゃないかしら？:+1: :+1: :+1: :+1::+1::+1::+1:

- この例では、各システムのマイナスの値のテストがされていたら、気づけた問題なんだろうか
- > P.58 「注文」、「注文明細」、「本」はこのドメインにおける明示的（explicit）に表現される概念として専用の型を使って表現される一方、「冊数」、「書籍名」、「ISBN」、「金額」は暗黙的（implicit）に表現される概念としてint,Stringなどの汎用的な型で表現される傾向があります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934424791245525022)
- 耳が痛い。。。結構やりがちですね
- 「本」は明示的にドメインオブジェクトにしやすいけど、なんで「冊数」、「書籍名」などはドメインオブジェクトにしない傾向があるんだろう？　ぱっと見たときにわからない概念だからだろうか？:+1::+1::+1:
- 「冊数」、「書籍名」はそもそも数字や文字列で表現されているので、脳内で考えたときに自然とドメインオブジェクトにできないのではないでしょうか？
- 意外と制約（冊数の上限/下限）とかバリデーションしてたりするのに、それがドメインオブジェクトとして表現されていない気がする。:+1: :+1::+1:
- 数字は int など、文字列は String と最初に覚えるため、オブジェクトにするという発想がなかなか出てこないのではないかと。

- > P.62 浅いモデリングを行って、概念を暗黙的な表現で実装してしまうと、その中にバグや安全性を脅かすコードが含まれてしまうリスクが高くなります。
- 浅いモデリングのリスク、今までの事例も全てこれを指摘したもの:+1:

## 疑問
- > P.57 開発者がうまくモデリングできたと最初に思った時点で、それ以上は深く考えたり疑問を抱いたりすることをやめてしまい、さらにそれ以降の計画を立てたり考慮したりすることをやめてしまったからだと考えています。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934419388101177375)
- 最初は深いモデリングできたけど、継続的に同じレベルで更新できたりできなかったということなのかな？それとも最初からその場しのぎだったのかな？どっちのことを言っているのだろう
- 最初から深いモデリングするのは現実的には無理では？:+1: :+1::+1::+1::+1::+1::+1::+1:
- 「コード書いた！よし、動いたぞー！！」で終わってしまって、フィードバックが動いてなさそう？？:+1:

---

# 2.3 深いモデリング（deep modeling）
## 目安の時間
- 22分

## 感想・気づき

- > P.63 対象のドメインから抽出する概念を選択した結果がドメイン・モデルとなるのです。
- ドメインモデルの説明。わかりやすいかも:+1:

- > P.63 このときに意識するのは「この概念をどのようにコードで書くのか？」ではなく、「この概念をどうすれば理解できるのか？」ということです。こうすることで、モデリングの際にさらに深い話を聞き出せるようになり、多くの場合、ドメインに関する議論と実装を繰り返し行なうようになっていきます。
- 前者の方に目が行きがちだけど、それだと浅いモデルとなって思考停止になってしまうことなんだろう　:+1::+1::+1::+1::+1::+1:

- > P.66 NOTE：コードとはコード化された知識のことであり、まさに名前がそのことを表しています。
- 前にあった「コードが知識を表現する」という話題に対する著者の考え:+1: :+1::+1:

- > P.67 ソフトウェアを安全にするために本書を通して訴えていることは、暗黙的に表現されている概念を明示的に表現することです。
- 深いモデリングをして必要となる概念を明示的にしていくことが重要ということでしょうか:+1:

- > P.67 一方、すべての概念を明示的に表現することへの反対意見としてよく聞くのが、クラスの数があまりにも多くなる、ということです
- この反対意見はよく聞くけど、ちゃんとレイヤー分け（少なくともドメインとそれ以外）とパッケージを分けておくことによって、そこまで管理しづらくなる印象はない :+1: :+1: :+1::+1:

- > P.67 浅いモデリングを行ってしまうと、対象ドメインについて理解する機会を失うことにもなります。
- 浅いモデリングからの悪循環:+1:
- 一度浅いモデリングで始めると、そこから深める = 実装が面倒になる という解釈になって、深めるのを避ける重力がチームに蔓延するのを感じたことがある。:+1::+1:
- 業務担当者によっては深いモデリングに非協力的な人もいそう(だって、その人はシステムによって仕事を奪われてしまうので)

## 疑問

- > P.65 TIP: モデリングの際、上限について聞くようにしましょう。そうすることで、興味深い情報が出てくることがあります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/934428091747553281)
- これ以外に、みなさんが「こうやると深い情報を聞き出せる」みたいな訊き方、キーワードってありますか？ :+1::+1::+1: :+1::+1::+1::+1::+1::+1:
- 個人的には、上限、下限、0やマイナスの場合、存在しない場合、失敗したパターンなどを聞くと、結構情報が出てくる印象があります。
- モデル要素間の数量的な関係 (1:1かn:mかなど) は必ず意識する

---