DDD本 7章 言語を使用する：応用例
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

- [2020/12/19 Sat 20:00-](https://discord.com/channels/432531367427964929/740202765619429487/787182180064952370)

# 自己紹介

- なかじま（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章 序章
## 目安の時間
- 7.5分

## 感想・気づき
- 全体として、テキストにモデルの要素（**貨物**や**配送記録**など）が繰り返し繰り返し登場し、やや詳細な実装よりの設計を考える時にすらも利用されている様が、章を通じて描写されている
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789815068950921227)
- これを踏まえて p.27-p.30 を見返してみると、中々面白いかもしれない:+1:
- 全体として、この章では「で、2部のパターンを使ってみるとどうなるの？」の例示をしたいのだろうなと
- 本文ではなく勉強会に対しての気付きとして、「読んだ範囲全体」という項目があっても良いかもしれない:+1:
- 節や項に留まらない、全体を通じた感想や疑問を書くスペースがあると、また色々面白いものが集まるかもしれない
- 「これこの節かな、いやそれともこっちかな……」みたいに迷って結局書かれずに終わったコメントがもしもあったら（想像）、そうしたものを拾う口になるかも？

## 疑問

---

# 貨物輸送システムを導入する
## 目安の時間
- 7.5分

## 感想・気づき

- この章での説明は、ある程度必要な概念がそれなりの形になっている状態から始める、という説明が入っているので、それを考慮しながら読み進めないといけないなと思った
- 0→1のモデルを図示するプロセスは省かれている
- 「配送仕様」は仕様パターンに従っているとある。荷出し地と到着時刻だけ定義して、その仕様を満たせるかどうかって意味っぽい
- 貨物は追跡IDを持った「何か」として限定しておき、具体的な配送手段は「配送仕様」の裏側に隠すといったことを明示的にしているのが、ここでのポイントか
- P.166「また、普通、モデルが設計をよりよく支えるように改良される際には、ドメインへの新しい洞察も反映するように改良されなければならない。しかし本章では、やはり説明を明確にするため、変更のきっかけは、モデルと設計を結びつけることに限定する」
- ここの一文を見逃してしまうと、大変なことになりそう
- 輸送のことをあまり知らないせいか配送仕様と位置の関連「荷出し地」を発送元と解釈してしまってクラス図が何を言っているかわからなくなり混乱しました。輸送側からみて荷物を出す＝配送先（Goal)ととらえてようやく読めるようになり、ユビキタス言語の指す意味をきちんと合わせておくことの大事さを初っ端から痛感しました。:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789818122072358925)
- :memo: 荷出し地 = destination

## 疑問
- > そして、モデルを変更するきっかけとなるのは、構成要素パターンを採用した実践的な実装に対して、モデルを結びつける必要が生じた場合に限定する。 - p.166
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789816763989753887)
- 「構成要素パターン」とは？
- つまるところ、2部で語られてきたパターン達のことっぽい
- 原文を見ると *the building block patterns* となっている :+1::+1::+1:
- > changes will be motivated strictly by the need to connect that model with a practical implementation, employing the building block patterns.
- building block = 建材、建築用ブロック
- *the* が付いていることから、既に言及済みで共通認識となっているもの
- 他方、 *The* や *Building Block Patterns* のように大文字始まりではないので、特に固有名詞を指すものではなさそう
- 7章が第二部の最終章として配置されていることも踏まえると、ここの「構成要素パターン」が指しているのは、おそらく二部で説明されてきた諸々の実装パターンっぽい:+1:
- 補足するなら「（ドメイン駆動設計を成立させるための）構成要素（となる各種の）パターン」ぐらいか
- :memo: [DDD難民に捧げる Domain-Driven Designのエッセンス](https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/)
- 「第2部 モデル駆動設計の構成要素」と、タイトルで「構成要素 (building blocks)」と呼んでいる

---

# ドメインを隔離する：アプリケーションの導入
## 目安の時間
- 7.5分

## 感想・気づき

- なんとなくモデルの構成要素（VO、Entity）から作るのか、トップレベル（ユースケース）から作るのかって、いろんな考え方があるけど、エヴァンス本の一例だと最初にユースケースレベルで分けているようにも見える
- もちろん、本の説明の仕方もあるだろうし、プロジェクトによってやり方は異なるから、一概に良い悪いは無いけど　
- P.166「これらのアプリケーションクラスは調停役（coordinator）である。調停役は自分で出した質問に対する答えを考え出してはならない。それはドメインの仕事である」
- これは、アプリケーションクラス内で特定のビジネスロジックを持ってはいけないって事であり、入出力に関するロジックも別に移譲する事だとも思った
- P.166「これらのアプリケーションクラスは調停役（coordinator）である。調停役は自分で出した質問に対する答えを考え出してはならない。」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789821310468751430)
- まさにTell, Don't Askのことを言ってるなと思った:+1::+1::+1:
- アプリケーションクラスで言及しているのは、ここがビジネスロジック流出を防ぐ生命線だということを示唆してそう:+1:
- > ユーザレベルのアプリケーション機能を3つ識別して - p.166
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789820291609002015)
- 章冒頭で説明された要件の実現が、ドメイン層ではなくアプリケーション機能という文脈で語られているのが興味深い:+1:
- 改めて本章の図（p.163, p.181）を見返すと、「荷役の追跡」「貨物の予約」「請求書の送付」といったいわゆる「業務」は、ドメインモデルを表現しているだろう図には登場していない:+1:
- 図に登場するのは、あくまでこれら業務を実現するための知識および知識体系:+1::+1::+1:
- 「請求書」は登場するが、「請求書の送付」は見当たらない
- 「追跡」「予約」に至っては、直接は全く登場していない。
- それを可能とするための知識（「経路仕様」や「輸送日程」など）はふんだんに表現されている
- 各種要件の具体的な実現は、ドメインモデル（およびその図）においては直接は達成されていない
- 業務を実現するための知識・ルールはドメイン層で定義されるが、実際にそれらを使って具体的な「業務」を定義しているのはアプリケーションっぽい？:+1::+1::+1::+1:
- [「アプリケーション＝応用」という話](https://discord.com/channels/432531367427964929/784026333113483274/789507920684515360)にも繋がりそう
- 個別具体的な「業務」は、ドメイン知識（≒業務知識など）を応用することで形作られ、実現可能になる、的な

## 疑問
- P.166 「深く分析しなくても・・・・できる」はちょっと雑では・・。（簡単にわかる状況だったというテイで読み進めましたが）→と思いましたがP.163の最初に要求が書いてありましたね。:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789819352924815401)
- p.177以降の再設計に入りやすくする（「これ厳しいな、一度立ち止まろう」という流れにする）ため、わざと分析を省略してたりして（推測）

---

# エンティティと値オブジェクトを区別する
## 目安の時間
- 7.5分

## 感想・気づき

- 交換可能かどうか（明確に区別をしたいかどうか）、独自の同一性を持つか（他のオブジェクトとの関係性によって成り立つものか）という考え方一つありそう:+1::+1::+1:
- > これは実体を持つという、実際に使われる意味でのエンティティだ。 - p.166
- 「実際に使われる意味」とは？ :+1:
- 原文からすると「一般的な意味」、意訳するなら「俗に言う」ぐらい？
- > A Customer object represents a person or a company, an entity in the usual sense of the word.
- これはこれで、「俗に言うentity」 is 何:+1:
- 辞書的意味をそのまま使って良さそう
- > something that exists separately from other things and has its own identity
- https://www.oxfordlearnersdictionaries.com/definition/english/entity?q=entity
- 「他から独立して存在し、かつ同一性を持つもの」ぐらいか
- > モデルにおいてもエンティティとして扱える。 - p.166
- 「実際に使われる意味でのエンティティ」との対比を考えれば、これはDDDの文脈における「エンティティ」を指しているっぽい。
- 原文見ると、 *entity* と *ENTITY* が明確に使い分けされてる……！
- 5章の「エンティティ」でも、DDDにおける「エンティティ」は *ENTITY* *ENTITIES* と表記されている。
- > An object defined primarily by its identity is called an ENTITY.1 ENTITIES have special modeling and design considerations.
- 7章の該当部分
- > A Customer object represents a person or a company, an entity in the usual sense of the word. The Customer object clearly has identity that matters to the user, so it is an ENTITY in the model.
- 日本語版、 *entity* も *ENTITY* も同じフォント使ってるの、ダメでは？（ *entity* のほうは、通常と同じフォント使うべきだった気がする）
- せめて`（）`で原文の表記分けを併記してほしかった……

- > 荷役イベントと輸送機器イベント
- このあたりの「イベント」を *ENTITY* という枠で収めるのでなく、別に名前をつけて際立たせよう、認識可能性を高めようという感じで後々導出できるようにしようとしたのが *DOMAIN EVENT* という感じかな
- FYI: [Domain-Driven Design in PHP](https://www.amazon.co.jp/dp/B06ZYRPHMC)

## 疑問

- 「位置」の説明がわかりづらかったけど、これは値オブジェクトになるだろうか
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789822294498738177)
- たぶんエンテイティ(図7.2のノート)。でも確かにまわりくどくてわかりづらい。
- 「名前が同じであっても同一のものではない」ということでエンティティなんだと思います。P.180の図7.7でもエンティティに含まれています。値オブジェクトでもいい気がしますが...:+1:
- 「名前が同じであっても〜」ということ + p.164の図7.1で「位置」の属性として「港湾コード」というものが与えられていることを考えると、例えば市区町村合併や管理者の変化による港湾・地名の変化を想定しているのかなと
- ここでは「港湾コード」が識別子であり、それが一致しているなら呼称や名称が違っていても同一とみなす、的な
- 緯度/軽度を導入すれば値オブジェクトとしても表現できるかもしれません（ここでは必然性の薄さや複雑さによって棄却されてますが）
- p.169 図7.2 でも「位置のような基本的なエンティティは……」とあるので、少なくともこの章では「位置 = エンティティ」みたいですね
- :memo: 緯度/軽度を使って「位置」を表現するなら、値オブジェクトが良いかもしれない
- :memo: （日本基準だと）市区町村併合とか管理者の変化とかで、名称が変わることを想定してるように思いますね。
- :memo: 配送元、配送先を表現する位置になるので、固有の場所を表せないといけない＝同一性、ということでエンティティかと思いました。
- :memo: 配送システムの場合"key:位置ID, value:配送先住所"で十分だから、Entityで良いかと思いました。
- 「配送仕様」にある「配送記録の状態に対する仮説」はどういうこと？:+1: - p.167
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789821690996719626)
- 満たすべき「配送記録の状態」が配送仕様に記述されるという事を「仮説」と表現しているものと思われます。(原文ではどうなっているのか。)
- 原文では *It really expresses a hypothetical state of some Delivery History. * ですね。
- *a hypothetical state* だから、「配送履歴の仮状態」とか「配送履歴の仮説的状態」とか？
- 誤訳までいかなくとも、ミスリード感……
---

# 輸送ドメインの関連を設計する

-[discord](https://discord.com/channels/432531367427964929/740202765619429487/789823751684358154)

## 目安の時間
- 7.5分

## 感想・気づき

- P.168 「このアプリケーションが船の目録を追跡するなら、輸送機器移動から荷役イベントへ辿ることが重要になるだろう。しかし、我々のビジネスが追跡しなければならないのは貨物だけである。荷役イベントから輸送機器移動への関連のみ辿れるようにすることで、我々のビジネスに対する理解をとらえることができる
- ここから気づくのは、アプリケーションひいては、このソフトウェアを利用する人たちの要求を捉えることによって、モデルの関連を決めていくことができる。それが無いと制限がしづらく、間違った方向にモデルを捉えてしまうことになりそう
- 配送記録が荷役イベントという集約を保持しているが、独立した荷役イベントを見れるのであれば、集約内部を直接参照することと同義にも見える
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789825092267671552)

## 疑問

- P.168 「このアプリケーションが船の目録を追跡するなら、輸送機器移動から荷役イベントへ辿ることが重要になるだろう。しかし、我々のビジネスが追跡しなければならないのは貨物だけである。荷役イベントから輸送機器移動への関連のみ辿れるようにすることで、我々のビジネスに対する理解をとらえることができる」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789823751684358154)
- 仮に貨物と船の目録の追跡、どちらとも必要だった場合にはどういうモデルになったのだろう
- 双方向の関連は設計上複雑になるので避けたいから、何かしら別のオブジェクトが出てきたのだろうか？

---

# 集約の境界
## 目安の時間
- 7.5分

## 感想・気づき

- :memo: 集約の見つけ方の話しをしているので、ここ（P179）で大切なのは、 「独自の同一性があり」 「直接探す人はいないと思える」 「値オブジェクトなので」 「貨物自体から切り離して考えたとしても意味を持つ」 あたりですね。
- :memo: 「独自の同一性があり」 ... 顧客、位置、輸送機器移動
- :memo: 「直接探す人はいないと思える」 ... 配送記録
- :memo: 「値オブジェクトなので」 ... 配送仕様
- :memo: 「貨物自体から切り離して考えたとしても意味を持つ」 ... 荷役イベント

## 疑問

---

# リポジトリを選択する
## 目安の時間
- 7.5分

## 感想・気づき

- P.174「貨物集約の境界内にあるものはすべてコピーし、そのコピーを一部修正したが、集約の境界外のものに対しては、全く影響を及ぼしていないことに注意して欲しい。」
- 永続化云々ではなく検索の要否がリポジトリを作成する基準になっている。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789829345489190953)
- リポジトリ数＝集約数だと思っていたが、例外があるのだなぁ。

## 疑問

---

# シナリオをウォークスルーする

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789830363722678313)

## 目安の時間
- 7.5分

## 感想・気づき
- このクロスチェックはやはり、ドメインエキスパートとモデルを使って話し合うからこそ出てくるものだろうなと思いました。
- > 貨物はエンティティであり、集約のルートでもある。したがって、コピーは慎重にしなければならない。 - p.173
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789830433654308894)
- ここの「コピー」は単なる処理的・実装的な意味での「コピー」ではなく、ドメイン知識としての「コピー＝プロトタイプとして古い貨物を使用する」が持つ意味を表現している。
- この手の「コピー」が重要なものとして見られるシーンに遭遇したことが無かったので、興味深い
- 強いて言うなら、この「コピー」にも名称を与えたい気はする。

## 疑問

---

# オブジェクトの生成

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789832088467144734)

## 目安の時間
- 7.5分

## 感想・気づき

- P.174「貨物と配送記録との間にある、この双方向の関連が意味するのは、貨物も配送記録も相手を参照していなければ完全ではないということなので、両者は一緒に生成しなければならない」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789832165885214740)
- 複雑な生成知識をファクトリに閉じ込める重要性が一つわかった気がする:+1:
- P.176「ファクトリの責務は、どのクラスがインスタンス化されるべきかと、それをどうやって初期化するかを理解していることである」

## 疑問

---

# リファクタリングのために立ち止まる：貨物集約についてのもう1つの設計

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789833586093588480)

## 目安の時間
- 7.5分

## 感想・気づき

- P.177 「荷役イベントを追加する時に配送記録を更新しなければならないことから、貨物集約がそのトランザクションに巻き込まれる」
- 前節の話と合わせて読んでみると、すごく問題点がわかりやすくなった。
- 荷役イベントは今の所独立しているのに、そこの変更によって貨物集約が巻き込まれるのはおかしい話である

## 疑問

- P.177 「配送記録が持つ荷役イベントのコレクションをクエリで置き換えることにより…」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789833635577987132)
リファクタリング前は、貨物エンティティのプロパティ（荷役イベントのコレクション）として存在していたが、リファクタリング後は、プロパティは削除され、配送記録を取得するためのメソッド（つまりこれがクエリ？）にしたということ？:+1::+1:
- メソッドを作ったわけではない

---

# 輸送モデルにおけるモジュール

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789835519323406357)

## 目安の時間
- 7.5分

## 感想・気づき

- 図7.7がインフラストラクチャ駆動と言っているのは、エンティティ、値オブジェクト、サービスといったパターンでモジュール分けしているからと理解:+1:
- 図を見ているだけでも、エンティティと値オブジェクトのモジュールの依存関係が激しいのでかなり危ないパターンに見える
- 図7.8は顧客、請求、輸送と概念ごとのモジュール分けしているので、モジュール間で見た時に、「顧客と輸送、顧客と請求は関連があり、請求と輸送は関連がない」と一段上から眺めた時にわかりやすくなっている
- P.181の図7.8を見て、ストーリーを語れる、といった文章を読んで、良いモデルというのはモデル図などを見て、ストーリーが語れることというのも、一つありそう。:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789835599783788574)
- もちろんそれだけが全てでは無いと思う

## 疑問

---

# 新機能を導入する：配分チェック

- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789837283527360532)

## 目安の時間
- 7.5分

## 感想・気づき

- イールドマネジメントをよく知らなかったので。なるべく省スペースで単価の良いものを積んでいこう的な発想だろうか。
- イールド
- anahd.co.jp/investors/data/annual/pdf/13/13_30.pdf
- 旅客1人に対する1キロ（または1マイル）当たりの収入単価。収入÷旅客キロによっても算出される。
- イールドマネジメント
- https://www.tourism.jp/tourism-database/glossary/yield-management/#:~:text=%E3%82%A4%E3%83%BC%E3%83%AB%E3%83%89%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%A8%E3%81%AF%E3%80%81%E3%83%9B%E3%83%86%E3%83%AB,%E5%BF%85%E7%84%B6%E7%9A%84%E3%81%AB%E4%BD%8E%E4%B8%8B%E3%81%99%E3%82%8B%E3%80%82

- P.183 「最初は販売管理インタフェースなどと予防と考えるかもしれない。だがそれでは、言語を活用してより役立つ輪郭に沿って問題をとらえ直す機械を逃してしまう。代わりに、他のシステムから取得する必要のある配分機能について、それぞれサービスを定義しよう。そのサービスを実装するクラスの名前は、こちらのシステムにおける責務を反映させて、配分チェックサービスとしよう」
- 「販売管理インタフェース」という無機質な呼び方をするより、「あるタイプの貨物をどれくらい予約していいのかチェックしたい」という責務を反映させた「配分チェックサービス」として定義したほうが、わかりやすいよねって話かな:+1::+1:
- 仮に自分で「配分チェックサービス」を実装するとしたら、別個に販売管理インタフェースなるものは定義しておいて、サービス内部でそのインタフェースを使い、外部システム（販売管理システム）のAPIやらデータスキーマが変わった時には、そこで吸収できるようにしておきたい感もある
- 外部システムからデータを取ってくるのと、それを自システム内で扱えるデータに変換するルールは、また別だと思うので。

## 疑問

- エンタープライズセグメントというものがよくわからない…。ビジネスの分割方法を定義した次元軸の集まり、という説明はわかったけど、それをクラス化することによって、インターフェースがシンプルになるというのはどういうことだろう？:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/789837365636104222)
- アナリシスパターンだと「企業内区分」になってますね
- ある次元軸で分類することですね
- 例えば、会社をエンタープライズセグメントで分類することこんな感じですかね
- 地理的
- 業種別
- 製品別
- あるフランチャイズチェーンの店舗検索だと
- 県
- 市
- 店舗(複数のフランチャイズチェーンがある場合)
- ものすごいザックリ言うと、絞り込みで検索するときのドロップダウンの項目ってイメージ
- PoEAA/POSAの次はアナリシスパターン(ファウラー先生)かなぁ:+1:

---

# 最後に
## 目安の時間
- 7.5分

## 感想・気づき

## 疑問

---