DDD本 12章 デザインパターンをモデルに関連付ける & 13章 より深い洞察へ向かうリファクタリング
===
###### tags: `エヴァンス本読書会`

/poll "アンケート第2問！ >>> この章は難しかった？" "お手上げ" "日本語難しすぎない？" "ちょっと何言ってるか分かんない" "まあ分かる" "余裕でした" "読んでない(小声)" "いま読んでる（小声）"

/poll "アンケート第1問！ >>> 『DDD輪読会への参加は何回目？』" "はじめて！" "2回目！" "3回目！" "100回！" "なんかいっぱい！！！"

# 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です。

---

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

## 感想・気づき

- > デザインパターンとドメインパターンの違いはなんだろうか？
- いきなりドメインパターンという単語が出てきた気がする:+1:
- 「ドメインパターン」が前に出たのは9章 Specification (p.229)、ここも唐突。
- P.316「パターンを同時に二つのレベルで考えなければならない」
- コードで用いられる技術的なデザインパターン:+1:
- モデルで用いられる概念的パターン:+1::+1::+1:
- ドメインの概念にうまく整合する形でデザインパターンを適用できると効果的、という話のよう。

## 疑問
- 「ドメインパターン」とは？:+1::+1::+1:
- 初出は「9章 - 仕様(SPECIFICATION)」のあたり
- 特に説明は無し
- 用語集にも、特に記載・定義無し
- 原文でも `domain pattern`
- p.315 冒頭に「モデル駆動設計のコンテキストにおいて、ドメインモデルの問題を解決することを意図」とはある
- 「ドメインモデルの問題」なので、「ドメインの問題」ではないのですよね。ドメイン-ドメインモデルの関係が問題領域-解決領域だったことを考えると、「ドメインモデルの問題」＝「解決領域における問題」であり、それは「解決方法をいかに実現するか」という話になって、やはりドメインに対するパターンとするのは無理がある気が
- 同意で、↓に書かれているように、モデルを表現するに当たってのモデリング/表現のパターンと言えそう。つまり、これを使ったところで、ドメインそのものがどういうものであるかに直接的に答えるものではないですね。
- :desuyone:
- ただ、一つだけ擁護するならば、DDDにおいては、分析モデル・設計モデル・実装モデルを区別しないように位置付けるという点で、これを「設計パターン」とすることに抵抗があったのかもしれない。 :+1:
- なるほどです。それらを区別するかのような意味が含まれてしまわないよう、少なくとも「設計パターン」という呼称を避ける意味はたしかにありそうな気がしました。
- モデル駆動設計を起点として、分析〜実装の各モデルを統合するという方針に即すなら「ドメインモデリングパターン」ぐらいだったらどうなるかな、みたいな印象です :+1:
- 「ドメインパターン」という呼称に違和感:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827866812007448607)
- 仕様パターンにせよ、Policyにせよ、あるいは二部の各種パターンにせよ、これらは設計あるいはドメインモデリングのパターンであって、「ドメインパターン」ではないのでは
- 強いていうなら「設計パターン」とか「モデリングパターン」ぐらいなら:+1:
- 「ドメインパターン」という呼称だと、ドメインそれ自体に、ドメインを問わず存在する一定のパターンがあるかのように、そして本書の各種パターンがあたかもドメインそれ自体を表現したものかのように見えてしまう
- 本書のパターンは「ドメインのパターン」ではなく、「実際に実装可能なモデルを定義するためのパターン」あるいは「モデルを反映した設計を実現するためのパターン」ぐらいが上限、という印象
- せっかく3章ではドメイン-ドメインモデル-設計を注意して使い分けしていた感があったのに、「ドメインパターン」という言葉の登場で、Evans自身も、ドメイン-ドメインモデル-設計それぞれと、各種パターンそれぞれが、各々互いにどういう関係を持つ or 持ち得ないのか、混乱している疑惑が生じた感:+1::+1:

---

# ストラテジー（STRATEGY）（別名　ポリシー（POLICY））
## 目安の時間
- 18分

## 感想・気づき

- > このルールは、行程それぞれが持つ特定の属性（潜在的に導き出されたもの）を、ある数字にまで煮詰めたものが経路選択の基準だという知識を伝えている
- ルールが付け替え可能というのはデザインパターンの側面としてメリットであるのと同時に、ドメインパターン（？）的には行程の属性（出発地点、到着地点）が経路選択の基準だとという意図を伝えている、ということなんだとわかってきた

- > 注：この議論では、経路選択サービスが輸送日程を検索する際に、実際には行程を評価していることが示唆されている。このアプローチは、概念的にはわかりやすく、それなりのプロトタイプ実装なら作れるかもしれないが、おそらく容認できないくらい非効率的だろう。このアプリケーションについては、第14章「モデルの整合性を維持する」で再度取り上げるが、そこでは同じインタフェースが、全く異なって実装された経路選択サービスによって使用される
- 非効率的らしい。行程を評価しなかったら何で評価するのだろう。

## 疑問

- > P.320 ドメイン層で技術的なデザインパターンを使用する場合には、別の動機を追加しなければならない。つまり、意味のレイヤをもう1つ追加しなければならないのだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827871362525036554)
- ここで言われている意味のレイヤとは一体なんだろうか:+1::+1::+1::+1::+1:
- 最初はインフラ層やドメイン層等のアーキテクチャ観点でのレイヤーの話かと思いましたが、単に「デザインパターンとドメインパターンの認識を、脳内のレイヤーで区別した方が良いよ」と言いたいだけなのかなと思いました。ストラテジーパターンとしてそのまま利用するのではなく、仕様というドメイン概念と一致しているのだから、これはデザインパターンでなくドメインパターンと意識した上で使用しようねみたいな（自信は無い）。
- ドメンパターンを表現する手段としてのデザインパターン、かも。

---

# コンポジット
## 目安の時間
- 18分

## 感想・気づき

- > P.322 コンポジットを構成するすべてのメンバを包括的に含む抽象型を定義すること。情報を戻すメソッドはコンテナに実装され、内容についての集約された情報を戻す。「リーフ（Leaf）」ノードは、それぞれ独自の値に基づいて、それらのメソッドを実装する。クライアントは抽象型を扱えばよく、リーフとコンテナを区別する必要はない
- いきなりコンテナという単語が出てきたけど、コンポジットの1要素？
- と思ったけど、貨物輸送経路のコンテナのことだと気づいた

- > P.322 どんなデザインパターンでも、ドメインに適用する際にまず気にすべきことは、パターンの考え方が本当にドメインの概念に合うかどうかである。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827875900665495572)
- デザインパターンを適用したら便利かもしれないが、それが本質かどうか（階層構造がドメインの本質なのか）を考えないといけない、ということか:+1:
- コードを変更する上では楽かも、と思って使用してしまうと、このドメインは階層構造なのか？　という疑問を抱かせてしまうかもしれない:+1::+1::+1::+1:
- 逆にデザインパターンだけ使いたい場合（ドメインには適用させない）はドメインの言葉を使わないような配慮が必要なのかもしれない

## 疑問

- P.325 図12.7 経路を詳述したクラス図
- 「完全経路」から「ドア行程」への「荷出し」はなぜ「3」？:+1::+1::+1::+1:
- (誤植の可能性もありそうだけど、答えがないっぽいのでスルーします）

---

# なぜフライウェイトではないのか？
## 目安の時間
- 18分

## 感想・気づき

- > 唯一の要件は、パターンが概念的なドメインについて何かを述べるべきであり、技術的な問題に対する、技術的な解決策にとどまってはならないということだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827877562872365086)
- 述べられないようであれば、安易な適用を避けたほうがいいのかもしれない:+1:
- けど、普通に技術的な側面で見てこのパターンを適用したら、ドメインは表現できてないけど楽になるよね、という場面は有り得そう:+1::+1::+1:
- パターンを使った場合には、述べられるように最大限力を使え、ということなのか。
- いま思ったけど、ここで「パターン」と言っていて、「デザインパターン」とは言っていない
- これは、今までの本書で紹介していた値オブジェクト、エンティティ、リポジトリなどの数々のパターンも含めての言及なんだろうと思う
- パターンを適用するのは良いが、それらが何かしらのドメインを表現できていないのであれば、よく言われるドメイン貧血症と呼ばれる状態になるのかもしれない
- ドメインモデル貧血症は、エンティティや値オブジェクトにおいて、データとふるまいが分かれてしまっている状態を表すものだと思っていました。パターン適用時にそのような状態が起きてしまっていたら、そうなのかもしれないですね。サービスに関しては、貧血症というより、「ドメインモデルとコードの乖離」みたいなニュアンスで捉えています。:+1::+1::+1:
- ドメインを表現しないパターンが入ってくると、ドメインを表現しているものとそうでないものの区別が難しくなっていって、モデル＆コード双方の保守性下がる要因になる、ということを言っているような気がします。

## 疑問

---

# 13章 序章
## 目安の時間
- 18分

## 感想・気づき

- より深い洞察へ向かうリファクタリングでの重点的に取り組むべき3つはとてもわかりみ:+1::+1::+1::+1:
- 全体的に、過去に触れた内容と被っているように見えた。第３部のラストだし、おさらいでもあるのかな。:+1:

## 疑問

---

# 開始

## 感想・気づき

- > P.330 問題のある場所を発見するのは、最も困難で不確実であることも多い
- とてもわかる:+1::+1:

## 疑問

---

# 探求チーム

## 感想・気づき

- モデルを探求するにあたり、対話をする上でのポイントが語られているのが面白いなって思った
- スコープと休憩の部分の短いミーティングを繰り返すというのが非常にわかると思った

- > p330あたり それまで考えたことについて一晩二晩寝かせている:+1:
- 何でもそうですけど寝かせるのって結構大事だなと思いました(感想:+1:

## 疑問

- > p330あたり 新しいモデルを探索するには、より長い時間がかかり、より多くの人々の参加が必要となる:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827884656376283207)
- この節で書かれているような長い時間をかけて複数人でモデルを探求する、ということをやったことがないなと思いました。皆さんはそういうことを仕事でされているんでしょうか？
- ここで書かれてるように、「選出した人」ってした時に、「選出された人以外」がモデルの改善に無関心にならないだろうかという懸念がありました(選ばれた人が決めたんだから従おう、的な)。

---

# 先達の技

## 感想・気づき

## 疑問

---

# 開発者のための設計

## 感想・気づき

- > ソフトウェアはユーザだけのためのものではなく、開発者のためのものでもある。
- この後に「開発者は何度も繰り返しコードを変更する」とある。正確には「繰り返し更新を行う開発者のためのものである」ということも重要だなと思う。(自分がわかればいい、的な開発者のためではないだろうということ):+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827889073712529448)

- > P.332 ソフトウェアはユーザだけのためのものでなく、開発者のためのものでもある。
- 全俺が泣いた
- コードを書いていてストレスを感じるのであれば、良い方向に積極的に開発者側から改善していって良いんだというメッセージに感じた。:+1::+1:

## 疑問

---

# タイミング

## 感想・気づき

- > 重要な概念が設計で暗黙的になっている（かつ、それを明示的にする方法がわかっている）
- このタイミングでやるのは同意
- 明示的にする方法がわかっていなかった場合でも、どのようにリファクタリングしていけばいいか？　とチームに話しかけたりはするかもしれない
- > ソフトウェア開発は、変更することで得られる利益や、変更しないことで生じるコストを正確に割り出せるような、予測可能なプロセスではない。
- 「イシューからはじめよ」という良書がある。自分の観測範囲では、この書籍を読んだ人ほど、問題解決のコスパを意識していて、それ故に、リファクタのような利益やコストの見えづらいものを後回しにしがちな印象がある。負債が問題化した時には、当初よりも返済コストが膨らんでいるので、ここら辺のモヤモヤがどうにかならないかなと常々感じている。:+1::+1::+1::+1::+1:

- > P.332 変更を完全に正当化できるまで待つのは、待ちすぎというものである。
- 金言に感じた。やるなら今。:+1::+1::+1::+1:

## 疑問

- 最後の段落、『括弧つきの「しなやかな設計」を導入してはならない。』とあるが、「括弧つき」と指定してる意図なんでしょう。体裁だけというのを強調したいということ？:+1::+1::+1:
- > Don’t introduce “supple designs” that are just demonstrations of technical virtuosity but fail to cut to the core of the domain.
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827881128819949599)
- 皮肉に聞こえる感じ
- 自称「しなやかな設計」
- （軽量）しなやかな設計

---

# 好機となる危機

## 感想・気づき

- > そうした状況は好機には見えないことが多く、むしろ危機のように捉えられる。突然、モデルの中に、明らかに不適切な部分があるとわかるのだ:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/827887415494049812)
- 今までは不適切だと思わなかったけど、ここでチームが理解の新しいレベルに達したことによって、「不適切」なんだと気付けるようになる
- これを新しく入ってきた人が深いモデルを見て、追体験をするのは難しそうだと感じる
- モデルとかコードで現在の状態を見た上で、今までの歴史みたいなものを口伝などで話して伝える機会がないと難しそう:+1:
- あくまで自分の体験だが、モデルが洗練されていると、新人の時でもスッと入ってくる印象がある。「現在のモデルがどういう経緯でこうなったの？」と疑問に思うケースはあまり無かった。ある場合は、歴史を知らないからというより、まだ別の欠陥が隠れている印象（洗練されていない時ほど矛盾があり、その矛盾が理解を苦しめる）。だが、過去の失敗を知らないので、過去の解釈を再び試すといったことは起きそう。
- 自分も自分の体験で、概念の認識が間違っていたことが数年サービスを運営した後で分かったことがあり、どうにかするなら大規模なリファクタリングとDBのマイグレーションをしないといけなくなったことがありましたが、確かに好機だ!とは思ったもののリスク大きいしやはり辛いなと思いました:+1::+1::+1::+1::+1:
- 新しい人が入って来て、それまでのモデルを「不適切」と判断し、「以前作った人が悪い」みたいなノリになる体験もありました。:+1:
- むしろ後から入ってよくわからないとき、そう感じがち（反省）。

## 疑問

---