セキュア・バイ・デザイン 第6章 状態の完全性（integrity）の保証
===
###### 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:をつけてください

- （例）集約とは？

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

## 感想・気づき

- > p.205 状態の変化はシステムにとって重要なことであり、多くのシステムはその変化によって何らかの影響をうけるようになっています。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964847975794892810)
- レガシーコードの問題の多くは「状態の変化がわかりにくい」か「想定外の状態変化を引き起こせる」だと思う。 :+1::+1::+1::+1:

## 疑問

---

# 6.1 エンティティを使った状態の管理
## 目安の時間
- 22分

## 感想・気づき

## 疑問

- > p.208 一方、後者の場合だと、同じビジネスルールであっても「積み込み時、飛行機に積み込める荷物はその飛行機に載った乗客がチェックイン時に預けた荷物だけである」という表現になります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964851333997924383)
- 前者が荷物に対してのビジネスルールであるのに対して、後者だと「積み込み時」というイベント発生時のビジネスルールになりそう。
- 前者の場合は「荷物」のエンティティにビジネスルールを実装すれば良さそうだが、後者だとどこでビジネスロジック書くことになるだろう？:+1::+1::+1:

---

# 6.2 正しい状態で生成されるエンティティ
## 目安の時間
- 22分

## 感想・気づき

- > pp209 全てのエンティティが生成された時から正しい状態となる設計をすることが最善の手段であると本書では考えています
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964862020891607100)
- 「xxxId」のように識別子となるIDをAuto Incrementにしていると、これが満たせないケースが多いなと感じた:+1::+1::+1::+1:
- IDがある状態とIDがない状態のエンティティが共存するので、`xxx.id == null`だったり、`xxx.id.nil?`のような条件分岐が、結構認知負荷になっていた(railsのプロダクションコード)
- 「え、idがないUser」がこの段階でありえるの？？状態になった
- ULIDとか使ってみたい
- > p.230 このような状態であっても、まだ、運用は可能なのですが、使用するO/Rマッパーのフレームワークについて十分に理解することが必要になるでしょう。
- データベース操作の手軽さの代わりに何をトレードオフしているかを理解し、状況に応じて内部構造も変えていくことが重要なのだと学びました。:+1:

- > pp214 この種のフレームワークは内部でリフレクションを使って空のオブジェクトを生成し、それから、データベースから読み込んだデータをそのオブジェクトに設定するためにSetterメソッドを読み出すようになっているからです
- 触れた経験のないフレームワークで、`Entity`というフォルダ配下のクラスが、このタイプだったので、初めてコードリーディングした時の違和感がものすごくあった

- > p.221 コマンドは状態を変えても戻り値を返さないものである一方、クエリは結果を返しても状態を変えないものとして解釈されています
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964863682016337920)
- 任意で、ユーザーが入力する項目など、コード例のように、`withXXXX`のようなメソッドを生やして、thisを返す方法で実装していて、違反している観点は、考えれていなかった:+1::+1::+1::+1:
- 取るに足らない違反と後で記載されていたが、頭の隅にもなかった、、、:+1:

## 疑問

- > p.219 このフルーエント・インターフェイスが目的としていることは、コードを自然言語（ここでは英語）で書いたテキストのように読めるようにすること
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964855609012928543)
- 日本語プロジェクトでも恩恵は得られるのだろうか？:+1::+1:
- 経験上、`.withクレジットカード()` みたいに接頭句は英語にした方がやりやすかったです。
- 自然言語のように読めることを重視しすぎると、モデルが歪むことも起きうるので、ほどほどにしておきたい。

- この節で出ている与信残高と予備口座みたいな、必須項目ではないものってどういう設計がいんだろう。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964860133542871050)
- サンプルコードにある、nullを許容した設計が気になる（プロパティをpublicにしなければ、クラス内でnullチェックすれば良いとはわかりつつ）
- 個人的には、どちらか持っていれば良いっていう表現は、与信残高・予備口座をまとめた別のドメインプリミティブになっていても良いのかなとも思った:+1:

- > p.231 そのビルダーの生存期間は短くなるように設計するのがよいでしょう。（中略）もし、オブジェクトの作成が非常に複雑で、クライアントとのやり取りを何回もする必要があるのであれば、初期化自体をエンティティ内で管理される状態とするのがよいでしょう。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964856866515582976)
- 複雑なビジネスルールを満たした上で生成する責務をビルダーに分離しているはずなのに、初期化をエンティティ内で管理させる（おそらくコンストラクタなど）というのは、どういう理由なんだろうか :+1::+1:

- 必須なデータが 3 つくらいならまだしも、5 個とか 10 個とか多くなる (コンストラクター引数が多くなる) と、ここであがってる生成パターンでもきつい気がしてます。それは別の問題、モデルを変更する必要がある*におい*ってことですよね? でもあるある……。

---

# 6.3 エンティティの完全性（integrity）
## 目安の時間
- 22分

## 感想・気づき

- Getter/Setterを排除する・可変オブジェクトを共有しない・コレクションを呼び出し側から操作できないようにしない
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/964866604481540126)
- これらはカプセル化が意識できていると自然に出来ていそう。:+1::+1:

- > p.239 ここでは、orderItemsメソッドを呼び出すことで、注文明細が格納されたListオブジェクトの参照を取得し、その参照に対して直接変更を行っています。このとき、Orderオブジェクトは自身が保持するListオブジェクトの状態が変わってしまうことに対して何も制御ができません。これは明らかにセキュリティの欠陥であり、実際によく見る実装です。
- これはカプセル化を壊してしまうという認識ではいたけど、セキュリティの完全性の観点で欠陥があるっていうのを知れたのは大きい

- > pp236 このように可変オブジェクトをデータ・フィールドに使ったり、・・・・（略）
- フィールドだと意図しない変更になるが、メソッド内のローカル変数で可変オブジェクトだと、スコープが広くなり辛い

- > pp241 Listオブジェクトが保持する要素を不変オブジェクトにすることです
- 不変にできるかは、言語に依存する気がした
- typescript(jsでも同じ)でやるときは下記のように実装して、フィールドを返すようにしないようにしたけど、これも不変であるとは考えていいのだろうか
- pp240のコピーコンストラクタになるのか

    class HogeList {
        private items: string[]
        
        fetchAll(): string[] {
            return [...this.items]
        }
    }

## 疑問

---