セキュア・バイ・デザイン 第3章 ドメイン駆動設計の中核を成すコンセプト
===
###### 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です。

---

# 第3章 序章
## 目安の時間
- 20分

## 感想・気づき

- ドメイン駆動設計を箇条書きで説明されている部分は、エヴァンス本の「日本語版序文」と一緒だった（DDD Referenceから引用しているから当たり前か）

- > P.72 このアプローチが実はセキュリティにも多大な影響を与えていることに私たち著者は気づきました。
- ほうほう。どう気づいたんだろうなぁ。

- > P.72 この章では、ドメイン駆動設計の中でもセキュリティに影響を与えるものを中心に見ていくこととします。
- ドメイン駆動設計自体との差分を考えて見ていくと面白そう:+1::+1:

- > P.73 システムが何をすべきかを定義する際、システムが何をすべきではないかも把握しなくてはならないからであり、ドメイン・モデルがまさにその助けとなるものだからです
- 大事
- 責務を明確に

## 疑問

- ドメイン駆動設計は前提として「開発がイテレーティブである」としているが、本書のアプローチもそれが前提になるのだろうか？
- そうだと思います

---

# 3.1章 深い理解を得るためのツールとしてのモデル
## 目安の時間
- 70分

## 感想・気づき

- P74-75にある空港の預け荷管理システムの例が実際にあった恐怖

- ネットワークルータは技術的な複雑さであり、空港の預け荷物管理システムは、ビジネス的な複雑さが（技術的な複雑さよりも）あったということか

- > P.75 ドメインは対応しなければならない複雑さ（critical complexity）
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939502590138417152)
- いいな、この表現。 :+1::+1::+1::+1::+1:

- > P.76 システムを完全に理解して、すべての起こり得る状況に対して問題なく振る舞えるようにすることは簡単なことではありません。（中略）そのため、セキュリティにとって、ドメイン／モデルの作成に意識を向けることが非常に重要になってきます。そうすることで、付属的な効果として、多くのセキュリティに関する問題、特に、ビジネス的観点における完全性の問題を回避できるようになります。
- ビジネス的観点における完全性は、間違ったドメインルールでデータが作成されたり更新されないようになる
- ビジネス的観点における完全性がいまいちわかってなかったが、-1冊が購入できるなど、ドメインルールに従ってない不正な値が作られたり変更されたりすることを防ぐ感じなんだな、っていう理解

- > P.77 ドメイン駆動設計は銀の弾丸ではなく、その価値は開発の対象によって変わります。
- ドメイン駆動設計が一般的になると銀の弾丸として価値の発揮しないものにも適用しようとする人が出てきそう:+1:

- > P.78 ここで言うモデルとは、図のことではありません。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939502778869502012)
- それな。:+1::+1::+1:

- 鉄道模型の例は理解しやすかった。素材（プラスチック）や重さ、動力が異なっていても、各パーツの比率や色が合っていれば、ちゃんと判別ができる。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939487196061249546)
- 鉄道模型の目的は鑑賞だから、色や形、パーツの比率が合っていることが求められる :+1::+1:
- この例すごいよなあ、エンジニア以外の人に目的を伝えるのに使えるなと思った:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:

- > 奇妙なことに、モデルと実物の共通点を見つけるよりも、相違点の方が簡単に見つかります。そうであるにもかかわらず、誰もが、この鉄道車両のモデルを適切なモデルとして認識します。その理由は、このモデルが実物の鉄道車両について私達が理解していることの本質を明らかに捉えているからです。 - p.79
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939495194112450611)
- 「本質」という語を用いているものの、続くp.80の「モデルとは、その対象となる現実の中で何が本質だと考えているのか、ということを捉えた結果」という記述から、ここで言う「本質」とは、「真の、普遍的な、第一位の、客観的な」といった意味合いのものではなく、むしろ、主観的かつ恣意的に選び取られるものとして理解する必要がありそうに思う :+1::+1::+1:
- 他、p82「豊富な情報を失う代わりに、厳格さを得たもの」という記述、p.84のオブジェクト管理システムと化したERPの話、「3.1.4 モデルの作成はモデルの選択を意味する」いったタイトルなどを踏まえても、ここで言う「本質」は既に有るものではなく選び取られるものとして見るべきと思われる :+1::+1::+1::+1::+1::+1::+1:
- （余談）サルトルを連想。「実存は本質に先立つ」など。
- > 人間は人間的な主観性を超えることは出来ないが、人間は自らを選ぶことに置いて人間の全体を選ぶ - 『岩波 哲学・思想辞典』p.669r 「実存主義」の項より

- 80ページの「モデルは現実の簡素化」の部分は原文は modeling かしら？とても気になって夜も9時間しか眠れません。:+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939498060080381952)
- 原文だと `A model is a simplification, but it must still be general enough so that you can capture some variations that you think are interesting.` で、 モデル = A model
- 後半の `some variations that you think are intersting.` は、訳からこぼれていそうな気がするけれど、大事なポイントに感じる:+1::+1::+1: :+1::+1::+1:
- 無前提に、無文脈に、普遍的に定義できるような「違い」ではなく、あくまで自分たちが関心を向けている「違い」を十分にとらえていることが大事なのだ、という点 :+1::+1::+1:
- 列車の模型で言えば、重さや長さは取りこぼしても良いが、サイズ比や色は列車の模型に対して関心を向けている箇所なので、十分にモデルへ組み込まれていることが大事、的な
- とすると、「モデル」は静止したものでなくて運動みたいな捉え方なんですかね :+1:
- ↓の説明を見る感じ、ここでは「モデルとは簡素化である」というよりは、「モデルとは、簡素化の成果である」という感じで理解した方が良いのかもしれません。p.73 l.19で「モデリング」という語も使われていたりするので、ここでイメージされている「モデル」自体は運動ではないかも。
- https://www.oxfordlearnersdictionaries.com/definition/english/simplification?q=simplification
- > [countable] the thing that results when you make a problem, statement, system, etc. easier to understand or do

- > P.82 ドメイン・モデルは単に現実を薄めたものではなく、豊富な情報を失う代わりに、厳格さを得たものです。本書でモデルが厳格であると述べる場合、その「厳格さ」が意味することは数学的な意味での「的確さ」や「正確さ」であり、概念、属性、関係、振る舞いが曖昧ではない、という意味です。
- 豊富な情報を失う分、いくつかの属性が厳格であること。曖昧にならない

- P83,84のMRPならうまくいくけど、ERPだとうまくいかないのは、MRPは製品とかの無機的なものは動きが一定なので、予想できる動きを機械化したものだけど、ERPは人が介在して思うように動かないので、あてはめができなかったのだろうなと。
- P85 2章でもあったけど、ドメインエキスパートへの質問の仕方は大切

- > 自転車に乗るロボットを作るのであれば、自転車に乗ることに関してほとんどのエキスパート…が有する知識よりも深い知識を持っていることが求められます。(p.88)
> 開発者がドメイン・エキスパートの頭の中を覗けたとしても、そこにはそのまますぐに使えるモデルが見つからない…ドメイン・エキスパートの中には真のモデルがないのです。…最高のドメイン・モデルを作り上げるためには、開発者とドメイン・エキスパートとの共同作業が必要不可欠であり、そのことを時間を掛けて何度も繰り返し行うことでモデルを進化させていきます。(p.89)
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939489531206467584)
- ドメインエキスパートに任せっきりじゃいかんよ、我々も協力してモデルをつくるんですよーというエモい話:+1::+1::+1::+1::+1::+1::+1::+1::+1:

- > P.88 自転車で右に曲がる際、実は、ハンドルを一瞬だけ左に引き（自転車を左に傾けて）、体を右に倒す、ということを無意識のうちにやっています。
- マジですか！:+1:
- これはガチのマジです
- この文を読んで、深いモデル=慣れた人はやっているけど素人がしていない事や行動 なんだろうなと感じた
- 自転車で自然に曲がるのって、体感で覚えるけど、1度目はまずその動きできないと思うし、ちょっと言語化しずらいけど
- 自転車運転って、本当に無意識が多くて、真剣に向き合わないとわからない世界なのが面白い。(ドメインエキスパートの選び方難しい)

- > P.89 つまり、ドメイン・エキスパートの中には真のモデルがないのです。
- これな。 :+1::+1::+1::+1::+1:

- > モデルを作成するには、多くの可能性のあるモデルの中から意思を持って選択していき、その中で、開発するシステムに対して要求されることにもっとも適したモデルを選択しなければなりません。つまり、モデルの目的を定義するのです。(p.90)
- ここまでのまとめ
- 前回ミノ駆動さんが、単一責任じゃなくて単一目的って話をしてたなぁって思い出した。目的によってモデルに残す属性が変わるという。

- > ただし、言語警察にはならないように注意しましょう。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939500806829408276)
- アンジャッシュ状態はまずいけど、身内の会話で「あれだよ、あれ」で通じてるときは指摘したりしないよねと理解。あくまでドメインについて会話するのが目的だから、意味が通じてるなら言葉は重要じゃないと示唆してると感じた :+1::+1::+1::+1::+1:

- > 例えば、物流関係者と開発者とのあいだで、「足(leg)」という言葉が荷物をある場所から別の場所まで同じ車を使って運ぶことを意味し、「足を終える(terminating a leg)」が目的地で荷物を下ろすことを意味すると決めておけば、両者の会話の中でこのような用語や言い回しを使って、意志の疎通は図れます。 - p.93
- グループ間でやり取りするプロトコルを定めておけば、その語に対応する色々な実装（表現）を各グループで内々に使っても、グループ間でのやり取りは引き続き成立する、的な様相をイメージ
- 「言語警察にはならないように〜(p.95)」の話も、↑のイメージを踏まえれば整理できそうか.グループ間ではなくグループの内部で話している分には、グループ間のプロトコルを拡張した独自の言語を利用しても良い、的な
- 日本以外でも足って言うんだなあ

- 3.1全体が、「真のモデルを目指す」ではなく「よりよいモデルを探索する」という感覚を、自分たちにとって必要なものを選び取るという態度を、読者に刷り込むためか、「モデルとは選択である」ということを手を変え品を変え、何度も繰り返し書いているように思う :+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939500359284588545)

## 疑問

- > ただし、言語警察にはならないように注意しましょう。（中略）ユビキタス言語の正確さが重要となるのは、システムについて話すときに正確さが求められるときです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/939482574932308018)
- 気をつけたいが、難しそう。実際の現場で使っている話があれば聞いてみたい。（行きすぎない程度に普及させる仕組みについて）:+1::+1:
- 具体的に聞きたいのはどういうところでしょう。言語警察にならないようにする取り組み？

---

-------------------------------------

# ===================後半(2/19)はこちらから===================

-------------------------------------

# 3.2 モデルをコード上で表現するための構成要素
## 目安の時間
- 30分

## 感想・気づき

> フレームワーク - p.96

- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944565957114863657)
- ここで言う「フレームワーク」≠ Web フレームワーク、UIフレームワーク:+1::+1::+1:
- 特定コンテキストとしての用語ではなく、一般語彙としての「フレームワーク」
- 『ジーニアス英和辞典 第2版』大修館 p.719
1. 骨組み、枠組み、構造物
2. 機構、構造、体制
- https://www.oxfordlearnersdictionaries.com/definition/english/framework?q=framework
> a set of beliefs, ideas or rules that is used as the basis for making judgements, decisions, etc.
- > *We are currently exploring new approaches within existing frameworks of practice and thinking.*
> the structure of a particular system
- > *We need to establish a legal framework for the protection of the environment.*
- 以降でも、↑の意味での「フレームワーク」がよく使われている

- > P.97 エンティティは自身が所有するオブジェクトの操作を調整する責務を有する。
- 所有するオブジェクトを外から自由に操作できるようにしてはいけない

- > P.103 完結した概念(conceptual whole)を形成しなくてはならない
- 値オブジェクトの性質は「不変性」ばかり意識してたので、この性質をあまり意識できていなかった :+1::+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:
- [discode](https://discord.com/channels/432531367427964929/911610565103845387/944564697305333810)

- > P.104 値オブジェクトはエンティティをもてないのですが、参照はできます。
- これは値オブジェクトの属性としては持てないが、振る舞いの中では参照できるという理解でよいのかな？
- 原文だと `It can also reference, but not contain, entities.`
- 保持 = contain, 参照 = reference
- フィールドとしては保持できないが、メソッドの引数だったりで参照する分にはOK、的な意味というイメージ :+1::+1::+1::+1::+1:

- > p.106 値オブジェクトは単なる値を保持したデータの構造体ではない、ということです
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944566306340999219)
- ほんとそれ。今の時点では振る舞いが無くてただのデータの構造体と一緒じゃんって、その時点では思うかもしれないけど、ちゃんと区別しておかないといけない:+1::+1::+1:
- この文章を読んで、IDDD本の値オブジェクトの章（6章）を読むと味わい深い。（概念的な統一体、Ward Cunninghamが言ってる完結した値 Whole Valueなど）

- > p.107 ここで言う不変条件の確認は一般的に妥当性（validation）と呼ばれる種類の確認ではないことにも注意してください
- この文章の後に書いてある住所の入力漏れは、そもそも住所が無い場合ドメインオブジェクトが生成されないということか

- > 集約内のオブジェクトは他の集約への`参照` を保持できる(p.108)
- 「参照」って何？「保持できる」「参照」と「保持できない」「参照」とは？

## 疑問

- 不変条件（invariant）の理解が自分の中で怪しい。 Ageが 0 <= value <= 150 であることは不変条件？　妥当性確認？
- `class Age { int value; }` の `value` が `[0,150]` を満たすことは不変条件
- そのオブジェクトが存在する限り満たさないといけないのが不変条件であり、その不変条件を満たすために確認するのが妥当性確認なのかなぁって思ってます。:+1::+1::+1:
- 不変条件等を確認せずに作ったり、バリューオブジェクトを使わずに `int` で扱ってた値を処理の直前に確認するのが妥当性確認
- という理解をしています(弱気/コード書きたい)
- 実際に制約をどのくらい厳密にするのかの決定が難しい。どういう値オブジェクトの実装にするのかって辺りが興味深い。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944562195147157544)

- > P.104 値オブジェクトはエンティティを持てないのですが、参照はできます。
P.108 集約内のオブジェクトは他の集約への参照を保持できる。
- 「持つ」、「参照する」、「参照を保持する」はどう違うのか？:+1::+1::+1::+1::+1::+1::+1::+1:
- 「持つ」= contain
- 「参照する」 = reference
- 「参照を保持する」 = hold references
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944556951541534750)

- 「外部でも一意な識別子」「グローバルに一意な識別子」
- この「外部」「グローバル」の使い方は、どこ由来なのだろう :+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944558645541232721)

- > 外部でも一意となる識別子を使うことには欠点もあり、その欠点の1つはセキュリティへの影響です。このことについては別の章で見ていきます。 p.99
- どの章だろう

- > P.109 集約を実装する場合、ルートとなるエンティティと集約は同じオブジェクトにします
- ルートとなるエンティティの中に、集約としての振る舞いを実装するという意味であってる？

- P.107 注釈の12に記載されている「論理的な状態のトランザクション」がいまいちよくわからない。集約内のエンティティなどを変更する一連の変更ということ？

- > P.108 ルートは集約内部にあるエンティティの参照を他のオブジェクトに渡せるようにすることが可能だが、その参照は一時的にしか使えないようにし、保持できないようにしなければならない。
- 他のオブジェクトに渡されたエンティティ（の参照）を保持できないようにする、というのはコーディング規約的にそうするという意味でしょうか？言語によってはそのような制限が可能なのでしょうか？:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944559851869204500)

---
# 3.3 境界づけられたコンテキスト
## 目安の時間
- 30分

## 感想・気づき

- 出荷部門のモデルの話をすると足りなかったり要らない概念がある、というのがコンテキストの分かれ目なのか:+1:

- > この原則について、構文的な重複（例えば、コードのコピー＆ペースト）を避けることと解釈している開発者が多くいますが、この原則が言及しているのは意味的な重複のことなのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944567755649216542)
- これは私も駆け出しのことろは勘違いしていた。元の説明というか、意訳が誤解を生んでいる？
- コーディング規約でDRYの原則について言及していることが多いので、さらに誤解を広めている気がする :+1: :+1: :+1: :+1::+1::+1::+1::+1::+1::+1::+1:

- > P113 統一した言語を使って不正確な意味を持たせるよりも、それぞれの部門で異なる言語を使うようにし、それらの言語を共存させる方が明らかに良いでしょう。
- 無理やり同じ言葉にしようと定義することをしていたので、ハッとさせられた。 :+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944569974280839229)

- > p.117 開発者は出荷部門の様々な人たちにこのモデルについて聞いて回ったところ、誰もが強雨痛の認識を持っていることが確認できました。
- 同じ出荷部門でも人によって意見が違って矛盾することがあるよね。色んな人に話を聞くのは良い作戦。

## 疑問

---
# 3.4 異なるコンテキスト間でのやり取り
## 目安の時間
- 30分

## 感想・気づき

- > P.118 コンテキストの境界はセキュリティの観点において重要な部分となります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944577096125153282)
- あまり意識したことはなかったが、確かにそうですね。:+1::+1: :+1:

- > p.120 このモデルにおける唯一の明らかな欠点は、コンテキストによっては不必要な概念が含まれるようになったことだけです。
- 一部のプロパティしか使わない、他はnullだらけのインスタンス…。:+1:

- > p.121 その理由は、この不変条件が成り立たない現象は、注文が改竄されたと解釈することができ、注文の改竄はセキュリティにおいて非常に深刻な問題だからです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944575250023215165)
- 結果的にセキュリティ侵害がなかったとしても、調査に時間を取られるからコストめっちゃ掛かるな…。:+1::+1::+1:

- > p.121 今回の「受け取り予定金額 > すべての製品の価格の合計」という不変条件は経理部門の中だけで意味を成すものだったのです。
- もしかしたら最初は共通のモデルにしていて良かったかもしれないけど、この不変条件が経理と出荷で変わることに気づいた時点で分けるべきだった気がする。:+1::+1:
- 今までの感覚からだと、出荷と経理でモデルが変わるというのはなんとなくわかるので、最初から分けておけばいいだろうとは思う

- コンテキストの境界を見つけ出すためのフックとして、コンウェイの法則を利用するっていうのはいい方法だなって思った :+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944574956988166204)

- 境界づけられたコンテキストが障害対応にどう影響しているのかは9章で出てくると書いてあるけど、障害範囲が限定できて調査しやすいっていうのがメリットな気はしている。:+1:

## 疑問

- (DDDよりの疑問になってしまうが) 巨大なシステムで各コンテキストから利用されるマスターデータ(大量)を扱う際のベストプラクティスなんだろう :+1::+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/944571430689980527)
- マスターデータをマイクロサービスにしたとして、トランザクションの問題が付き纏うだろうし、それってセキュアから遠ざかる？
- コンテキストを跨いで同じ意味を持つ事自体が不自然という意見もあるとは思うが、この疑問ではある程度同じものとして捉えられるデータをイメージしている
- 物流系などマスターデータ多そうだし、この課題が顕著になる気がする
- `コンテキストの境界はセキュリティの観点において重要` の文脈でふと気になった