設計やアーキテクチャについて学び直したいと思い、今回はセキュア・バイ・デザインを読んだ。
この本の作者は「オブジェクト指向入門」という本の思想に共感しているようで、自分もその本が大好きなので、共感できる内容が多かった。またDDD周りで定義されている用語を教えてくれるので、その辺りがぼんやりしてきていた自分にとって、再度学び直すきっかけになった。
以下のトピックが印象に残った。
- 集約によって、複数のエンティティの状態変化を常に正しくできる。論理的なトランザクション(DBのトランザクションではない)を作れるということ
- 妥当性確認は以下の順で行うことで、より負荷のかかる高度な妥当性確認を不必要に実施することを防げる
- オリジン：正当な送信元
- サイズ：適切なデータサイズ
- 字句的内容：正当な文字のみで正しくエンコード
- 構文：正しいフォーマットか
- 意味：意味的に正しいデータ
- ドメイン・プリミティブというものを作ることで、値自体が有効であることを保証する仕組みを作れ、セキュリティを上げられる
読書ノート
- ドメインプリミティブ 23
- クラス生成時にドメインの制約を満たしていることを保証する
- [ドメインプリミティブについて - Qiita](https://qiita.com/daikon510/items/ab70d61300bd2c641652)
- ユビキタス言語は、境界づけられたコンテキストの中のみ有効 95
- エンティティとは 97
- 自分自身を特定できる識別性(identity)を持っており、他のエンティティと区別できるようになっている
- 識別性はそのエンティティが生存している間変わることはない
- 他のオブジェクト、例えば、他のエンティティや値オブジェクトを持つことができる
- 自身が所有するオブジェクトの操作を調整する責務を有する
- 値オブジェクトとは 103
- 識別性を持たない代わりに、値で識別できる
- 不変
- 完結した概念を形成しなくてはならない
- 対象の概念を表すのに必要なすべての要素を含んで1つの個を成す
- エンティティは持てないが、参照はできる
- [エンティティ参照の事例、住所と国](https://chat.openai.com/share/b67f0d38-c66b-40e8-8901-b409077bfcda)
- 重要な制約が明確に定義されており、その制約を守らせるようになっている
- エンティティや他の値オブジェクトの属性として使われることがある
- 生存期間は短いことが多い
- 集約 108
- すべての集約には境界とルートがある。
- ルートは集約に含まれる1つだけしかない特別なエンティティ
- ルートは集約の境界の外から参照できる唯一のもので、次の性質を持つ
- グローバルな識別性を持つ
- 境界内のオブジェクトへの全てのアクセスを制御する
- 気づき：つまり集約の中のオブジェクトに直アクセスしてメソッドを呼んだらダメそう
- 集約内のルートを除いたエンティティはその集約内で一位となる識別性を持つが、その識別性は集約の外から認識される必要はない
- ルートは集約内部にあるエンティティの参照を他のオブジェクトに渡せるようにすることが可能だが、その参照は一時的にしか使えないようにし、保持できないようにしなければならない
- ルートは値オブジェクトの参照を他のオブジェクトに渡せるようにすることができる
- 集約を構成するオブジェクト間の普遍条件は、トランザクションが行われるたびに、その中で常に維持されるようにする
- 不変条件が複数の集約に広がってしまうと、正しい状態が常に保たれていることを期待できなくなる。ただし、最終的に正しい状態が保たれるようにすることはできる
- 集約内のオブジェクトは他の集約への参照を保持できる
- 気づき：複数のエンティティの状態変化をatomicに起こしたい場合、集約として管理するとやりやすい。それが（論理的な）トランザクションの観点
- コンテキストマップとは、異なるコンテキスト同士がどのように境界を超えてコミュニケーションを取るのかを示す概念的な見解 121
- 境界づけられたコンテキストを把握するために、既存組織のコミュニケーション構造を把握すると良い
- 結果として次のようなコンテキストマップを作れる
- セキュリティにおける基本原則は多層セキュリティ。複数のセキュリティ対策によって仮に一つ突破されても守られる 139
- 妥当性確認の分類。上から順に確認しておくことで、より負荷のかかる高度な妥当性確認を不必要に実施することを防げる 152
- オリジン：正当な送信元
- サイズ：適切なデータサイズ
- 字句的内容：正当な文字のみで正しくエンコード
- 構文：正しいフォーマットか
- 意味：意味的に正しいデータ
- 気づき：4.3妥当性確認の部分は全体的に面白い ☆
- 先にサイズを確認することで、字句的な妥当性確認などで膨大なリソースを消費することを防げる 159
- ドメイン・プリミティブ系の方式と対応されるセキュリティの課題 169
- ドメイン・プリミティブと不変条件: コードの不正確さ、エラーの起こりやすさ、曖昧さ
- Read-Onceオブジェクト: 機密性の高いデータの漏洩
- ドメイン・プリミティブの応用: ロジックがあまりにも複雑になってしまったことによるコードの負担
- ドメイン・プリミティブとは、その存在だけで、その値が有効であることを保証する厳格な定義がなされた値オブジェクトのこと。オブジェクト生成時に不変条件がチェックされる 171
- オンライン書店の、冊数など
- 気づき: エンティティや集約はここに入らないんやな。値オブジェクトよりさらに小さいイメージがある
- ドメイン・オブジェクトが外部に漏れると、クライアントの要求にドメイン・オブジェクトの構造が引きづられる。そのためDTOの一種を使って変換した上で公開する 179
- 気づき: GraphQLとかは、そのスキーマ定義がDTOっぽくなるよなあ
- Read-Onceオブジェクトとは、オブジェクトが生成されると、一度だけしかその中に閉じ込められたデータを取り出せないようにする 181
- クレジット・カード番号などのsensitiveな情報向け
- toStringのマスク
- 気づき: なんでこれがセキュリティに繋がるかあまりわかってないな
- 多分だけど、sensitiveな情報は大抵のケースでそのスコープ内でしか使われず、そこが最初の1回になる。それ以外で呼ばれていたらかなり怪しい、ってことか？
- 事例は188ページ。Tomcatが勝手にダンプしていたというのは面白い
- 状態を別オブジェクトに持たせるパターン 257
- 扱う状態が10を超えてくると管理が難しい。このような時にエンティティ・リレーが使える 273
- エンティティをフェーズごとにいくつかに分割する
- エンティティリレーが使える3条件 278
- 1つのエンティティにあまりにも多くの状態がある
- フェーズに分割する際、それらのフェーズが前のフェーズに決して戻ることがない場合
- フェーズからフェーズへの遷移がシンプルで、遷移先のフェーズが非常に少ない場合（理想なのは1つだけ）
- 設計を安全なものにするためのテストの種類 284
- 正常値テスト、境界値テスト、異常値テスト、極端値テスト
- リアクティブ宣言 358 ☆
- 気づき: スケーラブルなシステムを考える時の指針となる
- リアクティブシステムは、即応性、回復性、弾力性、メッセージ駆動を備える
- [リアクティブ宣言](https://www.reactivemanifesto.org/ja)
- リアクティブシステムとして構築されたシステムはより柔軟で、疎結合で、スケーラビリティがある。これによって開発が容易になるだけでなく、変更を受け入れやすくなる。これらは障害に対してより著しい耐性を持ち、たとえ障害が起きても災害を起こすことなく優雅に対処する。リアクティブシステムは高い即応性を持ち、ユーザに対して効果的な対話型フィードバックを与える。
- ログのサービス化による機密性・完全性・可用性（CIA）の向上 389
