DDD本 17章 戦略をまとめ上げる&エピローグ
===
###### 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:40 | 75分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:40-22:00 | 20分 | ふりかえり | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 大規模な構造と境界づけられたコンテキストを組み合わせる
## 目安の時間
- 10分

## 感想・気づき

- > P.493 多くのプロジェクトに見られる、より大きな課題は、完全に別々の部分がどう組み合わされるかを理解することである。そういう部分は、別々のコンテキストに区分けされることもある。しかし、それぞれは統合されたシステム全体でどのような役割を果たし、相互にどう関係し合っているのだろうか？　そうした問いに答えるためには、大規模な構造を使って、コンテキストマップを構成すればよい。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/870990897456750622)
- 一瞬、大規模な構造を使って、コンテキストマップをどう構成すれば良いのかと思ったけど、P.494の図17.3にあるような責務のレイヤとコンテキストマップを併用するということか。:+1::+1:

- > P.496 1つの構造を使用して、1つのコンテキスト内でモデルを構成することができるし、隣接するコンテキストにはまた別の構造を使用し、さらに別の構造でコンテキストマップを構成することもできる。しかし、この方向に進みすぎると、プロジェクトのための概念を統一した集合という、大規模な構造の持つ価値を蝕みかねない。
- コンテキストごとに別々の構造を取る、という選択肢も取れるのかという気づき。
- でも本書でも言っている通り、これを選択する価値よりもリスクの方が上回る場面が多そう

## 疑問

---

# 大規模な構造と蒸留を組み合わせる
## 目安の時間
- 10分

## 感想・気づき

- P.497 ドメイン自体が階層構造を成す、という発想はなかった。:+1::+1::+1:
単なる上流・下流といった関係性には収まらないものがありそうだと思っていたので凄く腹落ちした。

## 疑問

- > P.496 同時に、大規模な構造自体がコアドメインの重要部分になっていることもある。例えば、潜在能力、業務、ポリシーおよび意思決定支援からなるレイヤを区別することで、ソフトウェアが取り組むビジネスの問題にとって基本的な洞察が蒸留される。この洞察がとりわけ役立つのは、プロジェクトが多くの境界づけられたコンテキストに切り分けられていて、コアドメインにあるモデルオブジェクトがプロジェクトの大半にとって意味を持たない場合である
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/870992983913291837)
- :memo:コアドメインの重要部分 = 特定のパッケージとか特定のクラス群だけじゃなくて、「AとBが◯◯という仕方でつながる」「Aは意思決定を支援し、それを支えるポリシーとしてB・Cがある」というような関係性、その関係性そのものがコアドメインの重要部分であることもある、という理解
- :memo:（図17.6に引かれている線に対して）わざわざ書くことで、そのつながりあるいはつながり方を強調したい意図かと
- :memo:「より価値のある、有用な形として本質を抽出するプロセス」は、必ずしも余計なものを削るとは限らないと思います。「より価値のある、有用な形」を際立たせる、目立たせる、より価値・有用性を高めるという場合もあるかと。

- 境界づけられたコンテキストをレイヤごとに切り分けることによって、関連が整理しやすくなり、コアドメインの中にあるモデルが意味ない（たとえば、何とも関連していないとか）ことが把握しやすくなるという感じなんだろうか:+1::+1::+1::+1:

---

# まず評価する
## 目安の時間
- 10分

## 感想・気づき

- > P.498 1.コンテキストマップを描くこと。一貫したものが描けるか、それともあいまいな場所があるか？
- 最近ちょうど既存のコードを見ながら描いてみて、それをチームで共有してみた:+1::+1::+1::+1:
- 自分自身でも知らない概念があるなという発見があったし、チームで聞いたときに足りない概念を補填してもらえた
- 実際にコードをどう修正するか、という話までは出来ていないけど、「こういった概念はあるけど、コード上には表れていなそう」という話ができたので、少なくともきっかけまでは与えることは出来ている気がしている:+1:

## 疑問

- > P.498 プロジェクトにおいて戦略的設計に取り組む時には、現在の状況を明確に評価することから始める必要がある
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/870996727447035914)
- あらためて話題にすると、戦略的設計 is 何。:+1::+1::+1::+1:
- 我々はなぜ戦略的設計に取り組む必要があるのか:+1::+1:
- > p.498 プロジェクトで使われている技術はモデル駆動設計に向いているか？
- 逆に向いていない技術って何だろうか？:+1::+1::+1::+1:
- ドメインモデルだけを記述しようとしても技術的詳細が入り込んできてしまうようなフレームワークとか
- その技術の流儀に従うとドメインモデルの構造が歪んでしまうようなものとか

---

# 誰が戦略を策定するのか？
## 目安の時間
- 10分

## 感想・気づき

- アプリケーション開発から現れる構造は、アジャイル開発を進めていると割と見かけるパターンなのではないかと思った
- 戦略的設計のリーダーが自然発生的に表れている、という発言は面白い
- アジャイル開発を実践することによって、そういったリーダーが自然発生的に現れるのはなんでだろう。自己規律ができるようなチームをアジャイル開発では目指しているから？:+1::+1::+1:

- > このアプローチが特にうまくいくのは、そういう非公式なリーダが実践的な開発者である場合だ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/870999570807660564)
- 三章『実践的モデラ』とつながる話になりそう
- 他の箇所でも繰り返し強調されているが、「実際に触る」「フィードバックを得る」ことの重要性が、改めて言及されている:+1::+1::+1::+1:
- p.500 *アーキテクトが自分たちのルールを実際のプロジェクトに適用するのに、実際に手を動かしてフィードバックを得ることがなく、そのせいで非実用的な案ができていれば、開発者はそれを無視したり、抜け道を探したりするほかないのだ。* など。

## 疑問
- 顧客に焦点を合わせているのがどの辺りを指しているのか理解できなかった:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/870998705380147260)

---

# 戦略的設計上の意志決定を行うために欠かせない6つのこと
## 目安の時間
- 10分

## 感想・気づき

- この6つのことは、アプリケーションチームとアーキテクトが別々で働いている、ということが前提。
- アジャイルな開発が広まってきている昨今では、もしかしたらこの6つのことは自然と出来ていたりすることも多いのではないか

- > P.500 意思決定はチーム全体に伝えなければならない
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871003276022284289)
- > 象牙の塔のアーキテクトは無視されたり抜け道を作られたりすることも多い。アーキテクトが自分たちのルールを実際のプロジェクトに適用するのに、実際に手を動かしてフィードバックを得ることもなく、そのせいで非実用的な案ができていれば、開発者はそれを無視したり、抜け道を探したりするほかないのだ
- 一つ前の節でもあったが、戦略的設計をまとめあげる人は実際に手を動かしている開発者の一人であった方が都合が良いと思った:+1::+1::+1::+1:
- 現場の開発者の意思に対して、中央集権型アーキテクトの判断が遅かったり、否定ばかりだと、現場は無視して抜け道を探したり、失望して考えるのをやめたりする。。。というのをみたことがある。:+1::+1::+1::+1::+1:

- > p.500 **意思決定プロセスはフィードバックを吸収しなければならない。**
そこまで深い知識を唯一持っているのが、アプリケーション開発チームのメンバである。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871002130138406942)
- とても共感した。やはり実際にコードを書いて動かさないとなかなか知識は得られないと思う。:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:
- 開発の内製化が必要とされているのも、この部分が大きいと思う。:+1::+1:

- > p.501 アーキテクチャチームが、最も優秀な人材を全て吸い上げてはならない。
- 実際、アーキテクトチームに優秀なメンバーが吸い上げられ、開発が進まなくなった経験はあった。(推進できる人は全体のアーキテクト検討に時間を取られ、現場に残ったのはコード書き初めてまもない人ばかり):+1::+1::+1:

- > P.502 だが、うまくいっているプロジェクトには、他人のことに首を突っ込む人々が多い
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871002614488236082)
- すごくわかりみが深い。その前で言っている、チームでの交流をソフトウェア設計みたく、必要最低限にしようとする動きをするエンジニアがいるのも含めて:+1::+1::+1::+1::+1::+1::+1::+1::+1:

- 結局コミュニケーションなんだなあ:+1::+1:

- ITに限らずどの業界も分業化による弊害としてステークホルダー間(部署間だったり、企業間であったり)で責任を追いたくないから他所のことには無関心なことは結構あると思う。全部やれという訳ではないが、関心を持っていくことが大事ですね。(請負とかの形態だと仕方ない気もするけどなんだかなぁと思ってしまう...):+1::+1::+1::+1:
- 会社が分かれてしまうとかなり難しそうだけど、利害関係を超えて行動できるのって重要そう:+1:

## 疑問
- 6つって「意思決定は～」「意思決定プロセスは～」「計画は～」「アーキテクチャチームが～」「戦略的設計には～」「オブジェクトは～」のこと？

- > 進化する秩序によって、この落とし穴は回避できる。 - p.501
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871001603543560223)
- 進化する秩序は具体的なプロセスや手法の話ではなくて、「継続的に概念やそれに対する認識を更新あるいは刷新していこう」という態度についてだった記憶:+1:
- なんとなく、既に存在する構造を「天から与えられたもの」と捉えずに、自分たちで変えていく精神でいこうぜ、みたいな感じで読んでいました
- 態度でしかなく、なにかそうした活動を成立させる原理を示しているわけではないのだから、「できる」は飛ばしでは？:+1:
- と思って原文見ると *EVOLVING ORDER avoids this trap by emphasizing ongoing change to the large-scale structure in response to deepening insight* で、別に可能のニュアンスは無いように見える
- 「深まっていく洞察に応じた継続的変更を強調することで、進化する秩序はこの罠を回避する」ぐらいの訳なら、「そうした態度を取ることで、硬直化という罠を回避しようとする(努める)」ぐらいの意味で、違和感無い
- 訳が飛ばし気味？（なんで「できる」ってつけたんだろう...）

---

# 同じことが技術的なフレームワークにも当てはまる
## 目安の時間
- 10分

## 感想・気づき

## 疑問

- 「素人にもわかるフレームワークを作成してはならない」
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871004388821463060)
- 一見すると、「素人にもわかるフレームワークを作成してはならない」という行動をすべきだと読み取れたが、詳細を読んでいると「確実にフレームワークを台無しにする独特の態度」という説明に掛かっているように読み取れる。
- なので、ユーザーにとってわかりやすい技術的フレームワークを作るべきだよね、と言いたい？:+1:
- 本文読む限りでは、本当に題名の通りにしか読めなかったけれど、どのような読み取りをしたのか気になりました
- ちなみに、原文では *Don’t write frameworks for dummies* で、 dummy = 愚か者、とんまなどの意味（訳はかなりマイルドにしている）:+1::+1::+1:
- 以下のような記述から、ほんとうに題名の通り「素人にもわかるフレームワークを作ろうとするな」「かえってひどい目に合う」という話で良いかと:+1::+1:
- > 設計ができるほどには賢くない人も開発者の中にいると想定したチーム分割は、失敗する可能性が高い。これはアプリケーション開発の難しさを過小評価しているからである。
- > 設計ができるほどには賢くないなら、ソフトウェア開発を担当させてはならない
- 強烈 (^^ ; いろいろにじみ出てる感
- つらぽよ
- 「素人にわかるフレームワーク」こそ、以下の特徴を満たしてしまったものの具体例かなあと理解
- > ドメインモデルの表現力豊かな実装と容易な変更を妨げかねない
- > 主要な責任に対して意気込んで、(...)最終的に生産性の低い、作り込みすぎたアーキテクチャができあがってしまう
- ↑素人にわかるフレームワークこそ、豊かなドメインモデルを阻害しかねない、という理由がわからないんですよね。
- 「素人にわかる」ということは、しなやかで拡張性の高いモデルを実際にどのように利用してどのように課題を実現するかについて自力で考えて利用させるわけにはいかないですよね。そうなると、フレームワーク側が一通り先回りして「こう書けば動くよ」「ここに置くだけでできるよ」「拡張したかったらちょっと〇〇って書くだけで良いよ」みたいなところまでフォローしてあげなくてはならなくなる。それで平和に進むかと言うと、実際にはその先回りから何段階も横にズレていくので、そうなるとフレームワークがサポートしきれない範囲で利用者が途方にくれるか、フレームワークのサポート機能をつぎはぎしてそれっぽく動く（しかしドメインモデルとは乖離したものになる）しか無い気がします。
- この辺りはRailsとかを連想しながら読んでました

- マスタプランが失敗しやすいという話。代わりにAlexanderが提唱した「有機的秩序」の話が気になる。詳細が記載されている文献ってどこかにないかな:+1::+1::+1:
- それっぽいこと書いてあるやつ http://nomad-with-no-direction.blogspot.com/2015/11/1975.html
- 「生成システム」とか「創発」で検索すると楽しそう

---

# エピローグ
## 目安の時間
- 10分

## 感想・気づき

- > P.506 実際、成功したかどうかの真の評価は、ソフトウェアが長期間にわたってどれだけ役立つかで決まる
- これは、ソフトウェア開発にとっても役立つかどうか、含まれていそう

- > P. 511 改良し続けることこそがチャンスなのであり、整合していないモデルはリスクなのだ
> 我々は、使用するのも作業するのも楽しいソフトウェアをかけるのであり、さらに、成長するにつれて我々の進路をふさぐことなく、新しい機会を産み出し、所有者にとっての価値をつけ加え続けるソフトウェアを書けるのだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871007282446618644)
- 胸に刻みたい:+1::+1::+1::+1::+1:

- > p.515 パターン名は、チームで用いられる言語において、用語となることが意図されていて、本書でもそのように使用した。議論にパターン名が出てくる時は、注意を喚起するために(細)ゴシック体にしてある。
- 最初に書いて欲しかった。真ん中くらいで気づいた気がする。:+1::+1::+1::+1:

## 疑問
- > P.507 だが、結局、こうしたプロジェクトは変質して、従来のプロジェクトと同じようなものになる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/871008624477093888)
- 第9章のローンソフトウェアのその後でこう述べられているが、これは新しい開発チームがオブジェクトモデリングにそれほど傾倒していなくて、モデルとコードのループが完結していなかったからだろうか

- > P.509 ある時点で、モデルの特定の側面がデータベースの性能問題を引き起こしていることが判明した
- この性能問題ってなんだったんだろう。データを一覧画面で見たい時など、集約を再構成する時にN+1なクエリになってしまうとか？

---