セキュア・バイ・デザイン 第5章 ドメイン・プリミティブ
===
###### tags: `セキュア・バイ・デザイン読書会`

# 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です。

---

# （お試し運用）この用語がわからない、難しい
※ここに本を読んでわからなかった用語を書いていってください。
※私もわからなかった、という方がいれば、:+1:をつけてください

- （例）集約とは？

# 第5章 序章
## 目安の時間
- xx分

## 感想・気づき

## 疑問

---

# 5.1 ドメイン・プリミティブ（domain primitive）と不変条件（invariant）
## 目安の時間
- 27分

## 感想・気づき

- ドメイン・プリミティブ →　値オブジェクトに不変条件を加えたもの

- RFCなどの現実世界の規格に沿うことは大事だが、その上で今回対象のドメインにおいて必要な制約は何かを考え続けなければいけない
- メールアドレスの例もそうだし、のちにISBNから本IDに派生した話など。目的が変わるのであれば、それに応じたモデルを作っていく

- > p170 値オブジェクトに関して特に重要な特徴は、不変であること・・・（略）
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959778959850090546)
- エンティティもimmutableにすることができると思うが、皆さんがどういうルールで運用しているのか、気になった:+1::+1::+1:

- > p171 ドメイン・プリミティブはドメイン駆動設計の値オブジェクトのようなものです。しかしながら、ドメインプリミティブはその中に不変条件を持ち、オブジェクトの生成時にその不変条件が確認される、という大きな違いがあります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959778247120392273)
- なるほど〜と言う気持ちでした。DDDの値オブジェクトも不変条件を持つと思っていたがそうではないのかな。DDDでいう値オブジェクトの不変条件はもしかして値オブジェクトの外側で実施されるイメージ？:+1::+1::+1::+1::+1::+1:

- > p.175 この種の意味における軽微な違いはセキュリティの問題を引き起こす原因となりやすく、そのため、このような用語に異なる意味を持たせることは、他のシステムやドメインとのやり取りが発生する場合は特に、避けた方が良いでしょう。(図5.2)
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959797166757539872)
- こういうの、最初コード書いた人にはシステム固有、世界標準いずれかの思いがあっても、名前にその意志が見えないと改修した人によって意図が混ざってしまうのはある話かな。わかりやすくするの大事。 :+1::+1::+1:

## 疑問
- > p170 値オブジェクトの「完結した概念」の脚注: 「概念的な統一体」と呼ばれるもので、対象の概念を表すのに必要な全ての要素を含んで１つの個となる物を形成した概念のことである
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959775560438005770)
- 分かったようで分かっていない気がして不安になってきた、、、:+1:
- 国際通貨を扱う場合は、「数字」と「通貨の種別」が完結した概念って認識でいいのかな？？:+1:

---

# 5.2 Read-Onceオブジェクト（一度しか読み込めないオブジェクト）
## 目安の時間
- 17分

## 感想・気づき

- 率直な感想としてRead-Onceオブジェクトを使って、想定していないところで利用をしていたことを検知する仕組みはとてもいいなって思った。:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959784572801908746)

## 疑問

- Read-Once オブジェクトって、処理のリトライなどにはどう対処するのだろう。外からの通信に問題があったなどで、リトライしたくてももうデータが読めない？:+1::+1::+1: :+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959782784191328326)

---

# 5.3 ドメイン・プリミティブによってもたらされるセキュリティ
## 目安の時間
- 22分

## 感想・気づき

- > P.189 エンティティは本来課せられた処理の他に、データの妥当性や不変条件の確認などの責任も追わなくてはならなくなります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959789216945025025)
- 3.2.1節（エンティティの節）を見直すと以下のことが書かれている
- エンティティは自分自身を特定できるようにする識別性を持っており、他のエンティティと区別できるようになっている
- エンティティは自身が所有するオブジェクトの操作を調整する責務を有する
- エンティティはあるライフサイクルにおいて一意に識別できる。状態を持てることに集中するという見方ができるので、自身が持っている値の妥当性確認は値オブジェクトに任せると、責務に集中ができることだと理解をした。:+1::+1:

- > p.192 それでは、なぜ、コードを見る際に、この確証バイアスが影響してくるのでしょうか？まず、開発者が読むコードのほとんどは正しく実装されています。そのため、脳が「ここまでみてきたコードには今のところ問題ない」と認識してしまうと、無意識のうちに「残りのコードも同じく問題がないだろう」と思い込んでしまうわけです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959789929162997810)
- PRとかで確実に気づくの、無理。後続にあるコードの書き方も良いけれど、テストで気付きたい。
- 問題ないと思える環境って幸せだな〜。
- 複雑になると細部を簡単に見落としてしまう。心理学的要因にある。確証バイアス (confirmation bias) のような記述があったと思います。ありますよねぇ:+1:

## 疑問

- > ドメイン・プリミティブを使わない場合を見つけることが難しいくらいです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959786489573670982)
- クラスを新しく作ることにはどんな抵抗があるのだろうか？個人的にはパッケージ構造がざっくりしている時はそこから考える必要があるのでハードルの高さは感じる。:+1: :+1:
- クラス(ファイル)増やすと管理が大変になるって言われたことあります(分岐とループだらけになってる)

---

# 5.4 汚染解析（taint analysis）
## 目安の時間
- 22分

## 感想・気づき

- taint analysisというのは初見だったが、この手法の中で「コンストラクタにデータを渡していることは妥当性確認をしているよね」と汚染除去しているとみなしている。このことから、コンストラクタで妥当性確認をするドメインプリミティブの共通点があるよね、という話として受け取った。

- あまり汚染解析（テイント解析）についてはパッと検索してあまり出てこなかった:+1:
- NTTの資料はあった
- https://www.iwsec.org/mws/2012/presentation/1A1-1-slide.pdf

- 汚染解析とは違うけれど、最近よくいうトレーシングとか含めてデータの流れを追うのに識別情報付与するのは一般的アプローチなのかもと思った。(目で追えない。。。)　:+1:　　
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959796234820919346)

## 疑問

- > p199 汚染ビットをつけることで、そのデータがシステムをどのように経由しているのかを追跡する点です。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/959793706104389632)
- 汚染ビットを付与せずともデータ自体を追跡して、浄化(Validationなど)を実施した際にエラーとなることまで追跡できれば良い気もする、汚染ビットをつけてまで(一時的に)2重?でデータを保持することの利点があまり理解できなかった、詳しい方がいれば教えて欲しい　:+1:

---