セキュア・バイ・デザイン 第7章　状態の複雑さの軽減
===
###### 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です。

---

# 用語でわからないところ

- 例：集約がわからん

# 第7章 序章
## 目安の時間
- 18分

## 感想・気づき

- > p.246 Note: エンティティを設計する際に気をつけないといけないのが、そのエンティティが使われる環境です。その理由は、そのエンティティが単一スレッドの環境で使われるのか、それとも、複数スレッドの環境で使われるかに寄って、エンティティの実装が大きく変わることになるからです。
- 基本的に不変にすれば良いと思っていたから、あまり考えてなかった :+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/974996127638257684)
- > 不変オブジェクトにすると、状態を引き回す必要が生じたときに大分面倒くさくなるので、「単一スレッドからしか触らないなら、可変でも良い」という選択肢は有ったほうが吉、という感覚
- > 組み込みとか低レイヤだと、めっちゃ気にします。エンティティだからというか、なんに付けても常に気にしている状態ですが。

- > p.247 このような残高の結果になった理由は、2つのスレッドが同期を取って順番に処理を実行するようにはなっておあらず、同時に処理できるようになっていたことにあります。

## 疑問

---

# 7.1 部分的不変エンティティ（partially immutable entity）
## 目安の時間
- 18分

## 感想・気づき

- > p.248 そもそも、エンティティは状態の変化を扱うものとして設計されるものなのですが、そうであったとしても、エンティティの中で「この部分は可変にする必要があるのか？」ということを考えることが重要だと本書では考えています
- これには同意。全部が全部、可変である必要はないと思っている。

## 疑問

---

# 7.2 状態オブジェクト（state object）
## 目安の時間
- 18分

## 感想・気づき

- > p.253 しかしながら、実際の開発に置いて、開発者はエンティティを単なる構造体（privateなデータ・フィールドとそれに伴うGatter/Setterメソッドを持ったクラス）として見てしまう傾向があります。
- これはすごくよくわかる:+1::+1:

- > p.253 この把握することの難しさはテストの難しさにも繋がります。
- 依存関係が少ないほうが良い:+1:

- 状態オブジェクト(State object)はとてもわかりやすい。PersonにisMarriedって持たせると、可変オブジェクトとして扱わないといけないけど、MaritalStatusという状態オブジェクトとして作っておけば、Person側からは参照を不変オブジェクトとして持っておけば良い。可変な箇所を局所化かつ、意味のあるものとして纏めておける

## 疑問

- > p260 それでは、この状態オブジェクトをどのようにエンティティに組み込むのか見てみましょう
- リスト7.9のPersonクラスで状態のテストをどこまで行うべきかどうか気になる
- MaritalStatus#dateでは「結婚していない場合」、「結婚している場合」、「離婚した場合」の3パターンの条件分岐があるが、Person#dateのテストを書く時はどの状態でテストを行うと良いのか
- Person#dateから見るとMaritalStatus#dateの結果はvoid, 例外の2パターンだから、そこだけテストすれば十分か
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/975001657115021342)

- 各メソッドで if 文などで判定していた処理を状態オブジェクトというヘルパーに移動したけど、そのヘルパーを呼び出すルールは忘れないでね、ということなんでしょうか?:+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/974998513559695360)

---

# 7.3 エンティティ・スナップショット（entity snapshot）
## 目安の時間
- 18分

## 感想・気づき

- > p.261 データベースにデータを取得するまでの往復の時間はシステムがクライアントにレスポンスを返すまでの時間を遅くしてしまうからです
- 一般的にI/Oは計算時間より遅くなりがち :+1:

- > p.261 複数のスレッドからアクセスされるようになっても、エンティティを正しく機能させる、ということです
- セキュリティの完全性の話

- > p.266 有名なのがGreg Young氏が提唱するコマンド・クエリ責務分離（Command Query Responsibility Segregation: CQRS）のパターンやMartin Thompson氏が提唱する単一書き込み原則（Single Writer Principle）などがそれに当たり、両方とも同じようなことを唱えています。
- CQRSは知っていたけど、単一書き込み原則は初めて聞いた :+1: :+1::+1::+1::+1:

- 変更ができること自体が完全性を損なう可能性があるということは、たしかに納得いく話だなと思った
- ただエンティティの状態を変更するのがエンティティ自身ではなくて、ドメインサービスなどに逃されるのは、ちょっと気になる。（本書でも言及はされているけど） :+1:
- たとえば、addOrderItemメソッドもエンティティに実装しておいて、新しい不変なエンティティを生成するでも良いのでは。

## 疑問
- データベースが変更されたら、そのタイミングでスナップショットのインスタンスを作り直すのでしょうか？
- 例えばリスト7.11のOrderService#addOrderItemメソッドが呼ばれたら、そのタイミングでOrderSnapShotのインスタンスを生成し直す感じでしょうか？（具体的な実装方法が知りたいです） :+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/975006397920055326)

---

# 7.4 エンティティ・リレー（entity relay）
## 目安の時間
- 18分

## 感想・気づき

- エンティティリレーの導入の動機は、エンティティが管理する状態遷移の数が多くなるのを分割して、管理しやすくすること

- p.271の婚姻ステータスの例だと、生きているか亡くなったか。結婚しているか独身か、というのは1つのステータスではなくて、2種類のステータスに分けられそうな気がしている

- pp.272-273 私たち著者の経験から言えば、エンティティで扱う状態が5個までなら管理可能で、10個までならなんとか管理できるレベルだと考えています
- 5個でも体感多い気はしている
- この個数は、独身→結婚→離婚　という1ステータスの中の状態遷移の数のことか

- pp.278-279 エンティティ・リレーのシンプルさは、次のエンティティが生成されるときの状態が遷移前のエンティティの中で1つに決められていることから来ています。しかしながら、もし、生成される次のエンティティが複数あるのであれば、再びモデリングし直すことを考えたほうがよいでしょう。きっと、対象のフェーズを終わらせる状態がどこかにあり、その状態をエンティティに追加できるはずです。もし、それができないのであれば、複数のフェーズを1つのフェーズとして見ているのかもしれません。
- これは常に考えていきたい。もしかしたらドメイン的に関心のない状態まで含まれていたりとかするかもしれない。:+1:
- 特に、p.279にある、4つの箇条書きは意識したい :+1::+1: :+1: :+1::+1::+1:

## 疑問

- エンティティ・リレーを実際に現場でやっていらっしゃる人はいますか？　どんな風に実装していますか？ :+1::+1::+1::+1::+1::+1::+1::+1:

---