DDD本 16章 大規模な構造
===
###### 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:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

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

---

# 第16章 序章
## 目安の時間
- 22分

## 感想・気づき
- > 独立した作業を調整することにも役立つのだが、それは全体像に関する概念が共有されているからだ。すなわち、さまざまな部分の果たす役割が、どのように全体を構成するかについての概念が共有されているのだ。 :+1::+1::+1:
- 直近これができてなくて結合時大爆死したのでわかりみが深い
- > モジュール化によって、必ずしも設計に統一性がもたらされるとは限らない。(...)境界づけられたコンテキストがそれ自体で全体としてのシステムを見やすくするわけではない。(...)相変わらず理解する必要があるのは、補助的な要素とコアドメインに対する関係、さらに補助的な要素同士の関係である。 - p.447
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860844474979450890)
- モジュール化、コンテキストの境界づけ、コアドメインとそれ以外の区別は、専ら大きな全体をいかに分離するかの話だった。が、分離することで個々の部分を理解できるようになったとしても、それが自ずから全体の様相を示してくれないのはまさに。
- 「全体 ≠ 部分の総和」的なアレ :+1::+1::+1::+1::+1:
- この章のテーマは、今まで部分を区別し切り出す話が主だったのと対照的に、如何にシステムを「部分の総和」ではない、ひとまとまりの「全体」として統合し理解するか、なのだろうと思っている :+1::+1::+1:
- FYI: ホーリズム(holism)とか「動的平衡(福岡伸一)」とか:+1:

## 疑問
- p.446 で、ちょいちょい訳が怪しい箇所
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860843412831862784)
- > プロジェクトリーダは、わかりやすくしたことによる強みが活かされていないことが不満だった
- > the project leaders were not content to skirt the edge of comprehensibility.
- やや意訳を含めると「プロジェクトリーダー(たち)は、理解できる限界付近でうろうろするのでは満足していなかった」ぐらいか :+1::+1:
- *to skirt the edge of comprehensibility* を「わかりやすくしたことによる強みが活かされていないこと」は、ちょっと訳しすぎ感 :+1:
- > 複雑さのレベルが上がるにつれ、設計を組織化して、理解し操作できるようにする方法が求められた
- > They wanted some way of organizing the design so that it could be understood and manipulated as it moved to the next level of complexity.
- `A so that B` で BはAの理由という関係になる(Bするために、Bになるように)
- `it` は `so that` 前の `the design` を指していると読むのが順当か
- ↑を踏まえると、「設計の複雑さが次の段階に進むにつれて、むしろその設計を理解・操作できるようにするために、彼らは設計を組織化する方法を求めた」ぐらいか
- 本文の訳だと、色々係り結びの関係が変わっちゃってる感
- ↑を踏まえて、ここでプロジェクトリーダ(たち)が悩み求めていたことは、設計の複雑さが自分の理解できる限界近くに来ている状況と、その状況を克服できる（＝複雑さが増えてもなお設計の理解や操作を可能とする）ような方法だった、という整理になりそう :+1::+1::+1:

---

# 進化する秩序（EVOLVING ORDER）
## 目安の時間
- 22分

## 感想・気づき

- > P.447 モジュール化による分割を行っても、巨大なモデルは複雑すぎて理解できないことがある。
- めっちゃわかるぅ…！ :+1::+1::+1:
- モジュール化とは違うかもだけど、多くのマイクロサービスに分かれていて、どれが何と関係しているのかが掴めないことがよくある:+1:
- P450 「ドメイン層における大規模な構造はまだあまり研究されていない」と2000年ごろに提起しているけど、今は研究され、結果でているのかな？（自分がよく知らない）:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:
- XPでインクリメンタルな設計の話が出てくるけど、それに近いような気もする？
- アート・オブ・アジャイルデベロップメントの9章

## 疑問
- > P.451~452 大規模な構造を適用すべきなのは、モデルの開発に不自然な制約を強いることなく、システムを大幅に明確化する構造が見つけられた時だ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860849044527120384)
- P.448に"「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。"とあるが結局のところ「大規模な構造」って具体的にはどんな感じなんだろう？:+1:
- 「責務のレイヤー」の節に出てきた「意思決定支援」や「業務」、「能力」に当たる部分が「大規模な構造」という理解であっている？あまり「大規模」な感じはしないけど...
- P.452「大規模な構造の一般的なパターンのうちいくつかが、多様なプロジェクトで姿を現すのを私は目にしてきた。本章ではそのうち4つを取り上げる」4つとは、システムのメタファ、責務のレイヤ、知識レベル、着脱可能コンポーネントのフレームワーク。 :+1::+1:
- なるほど、ありがとうございます、読み落としてました。
- 逆に大規模な構造を適用するべきじゃないのはどんな時？文章からは読み取れないパターン？:+1::+1::+1::+1::+1::+1:
- P.451「大規模な構造を課すべきなのは、費用対効果が有効に働き、うまく整合する構造が見つかった場合である…システムが単純で、モジュールに分割することで理解できるのであれば必要ない」 :+1:
- 「責務のレイヤー」の節(P.467あたり)に出てきたぎこちない設計が生じてしまうようなトレードオフでのデメリットが上回る時が1つの例かな？
- > P.447 境界づけられたコンテキストがそれ事態で全体としてのシステムを見やすくするわけではない:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860852406061236225)
- あれ、じゃあ境界づけられたコンテキストの立ち位置ってなんだっけ？　崩壊と混乱が防止できるというのは、解決しようとしているドメインのあるべき姿が書いてあるだけで、認知の負荷が下げられないってことを言っているのか
- 各々のコンテキスト内部では一貫した知識体系が作られ、かつそれらは互いに境界づけられていることで、コンテキスト同士の衝突や混乱は回避できる。しかし、全体のコンテキスト同士の関連や、そうしたコンテキストと関係が積み重なってできあがる「全体」がどんな形をしているかは、個々のコンテキストを見ても、またコンテキストを並べてもわかるわけじゃないよね、的なお話かと。 :+1:
- ネジや金属板を眺めたり、それらを一同に並べたからといって、組み立てた時何ができあがり、それがどのような意味や役割を持つものか(車か、ガンダムか、ガラクタか)は自然と理解できるわけではない、というような。:+1::+1::+1::+1:
- p.451 で「大規模な構造は、一般に、境界づけられたコンテキストを横断して適用できる必要がある」とあるので、大規模な構造は境界づけられたコンテキストよりもさらに(マクロ|俯瞰|メタ)な視点にあることは確かでしょうね。
- 大規模な構造が解決したい問題というのは、モジュール単位の関係性、コアドメインと汎用ドメインの関係性などの認知の負荷を減らして、各部分の責務を詳細に知らなくても良いようにすること？ :+1:
- P.451にあった
- > 大規模な構造を使用するという選択は、個別の部分を最適に構造化することよりも、モデル全体としての扱いやすさを優先するということだ
- > P.450 きわめて野心的なアーキテクチャは、アプリケーション開発者からプログラミング言語そのものが持つ、親しみやすさと技術的な能力を奪ってしまうかもしれない。
- ここでいってるアーキテクチャはレイヤードアーキテクチャみたいなもの？イメージがつかないけれど、Railsみたいな一部を割りきって効率化に振りきったものを想像すればいいんだろうか？:+1::+1::+1: :+1:

---

# システムのメタファ（SYSTEM METAPHOR）
## 目安の時間
- 22分

## 感想・気づき

- 読んでいてあまり効果的なシステムのメタファが出てきた例はエヴァンス自身にも無さそう？:+1:
- あればいいぐらいで、システムのメタファは必須要件で無い感じ
- メタファは、往々にして誤誘導に繋がったりするので、個人的にはあまり好きではなかったたりする。事実をねじ曲げてでも、何となくイメージしてもらうための比喩、としては使うけれど、それ以上を期待しない派。

## 疑問
- XPのメタファが詳しく語られている文章を読んだことがないけれど、なにかおすすめの本はありますか？
- そもそもメタファの具体例ってどんな感じですか？ファイヤーウォールだけしか例がないのでイメージが付いていないです。:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860856022422519848)

# 責務のレイヤ（RESPONSIBILITY LAYERS）
## 目安の時間
- 22分

## 感想・気づき

- > P.470 図16.13, 図16.14
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860864960891191316)
- 実際に導入するかは別として、ドメインモデルの中でも「意思決定」、「ポリシー」、「確約」、「業務」、「潜在能力」といった層に分けることができて、しかも依存関係を1方向にコントロールできるという視点はあまりなかったので勉強になった。:+1::+1::+1:
- 『Design it!』の中で「アーキテクチャとは発見すべきものだ。」というフレーズが出てくるが、エヴァンス本と『Design it!』の繋がりがぼんやり見えた気がした。:+1::+1::+1:
- 輸送システムの例、要は「貨物というEntityに対して仕様を満たす経路を取得しろって依頼して、Entity内部で危険物経路ポリシーサービスを呼び出す形で隠蔽する構造」よりも、「経路選択サービスにこの貨物Entityにあった経路よろしくねと依頼してその内部に危険物経路ポリシーサービスが隠蔽されている構造」のほうがいいよね、という意味だと理解した。前者はEntityが何やってんの感すごい。:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860863450934542356)
- > P.469 意思決定支援システムは、業務や潜在能力といった他のレイヤに概念的に依存する。意思決定は何もないところではできないからだ。多くのプロジェクトでは、データウェアハウス技術を使用して意思決定支援を実装する。このレイヤは、はっきりとした境界づけられたコンテキストになって、業務ソフトウェアとは顧客/供給者関係となる
- 責務のレイヤの境でもコンテキストが分かれることがあるんだと、ここで気づいた。:+1:
- 「能力」という訳ってもしかしたら微妙なのではないか説を掲げている
- じゃあ何て呼ぶの？　と言われたら渋い顔するけども:+1::+1:
- 具体例を見て、ちょうどいい構造はちょっとやそっとじゃ発見できないよなと感じた。大規模な構造がないと理解が難しいほど大きなモデルでもない限り、無理に構造を産み出そうとしなくてもいいんだろうなとも思った。:+1::+1:

## 疑問

- >　P.457 それらの責務は、システムの高次の目的と設計について語るものでなければならない。モデルをリファクタリングして、各ドメインオブジェクトと集約およびモジュールの責務が、1つのレイヤに与えられた責務の範囲にうまく収まるようにすること
- 5章のモジュールをただ適用するのとまた別なんだろうか？ 責務のレイヤはモジュール化するときに指針となるようなもの？

- 図16.13と図16.14の読み方がわからない

- 責務のレイヤをモデリングで取り入れた例をお持ちの方いますか？:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/860859588681138207)

---

# ====== 7/17 後半はこちらから =============

# 知識レベル（KNOWLEDGE LEVEL）
## 目安の時間
- 30分

## 感想・気づき

- > P.477 知識レベルはリフレクションパターンをドメイン層に適用したものだ
- https://yusuke-ujitoko.hatenablog.com/entry/2016/11/19/185229
- REFLECTIONパターン ≠ 言語のリフレクション機能:+1:
- > プログラミング言語のリフレクションツールは、ドメインモデルの知識レベルの実装に使うためのものではない。リフレクションツールのメタオブジェクトは、言語の構成体そのものの構造とふるまいを記述するものである。 - p.478
- そもそもの「（プログラミング言語の）リフレクションツール」も、言語それ自体を対象としたREFLECTIONパターンの実現だったりするのだろうか(POSAが今手元に無いので確認できず):+1::+1::+1:
- そこまで汎用的にするような要件が無かったので、知識レベルのメリットがよくわかっていない:+1::+1::+1::+1::+1::+1::+1:
- > P.478 あらゆる協力なアイデアと同様、リフレクションと知識レベルには中毒性がある。このパターンは慎重に使用しなければならない
- といったことが書かれているので、モデルの関係性が状況によって変わるようなものを作らないようにするのを優先すべきなんだろうなと思う
- > P.480 給料の概念はモデルの中に暗黙的に存在し、従業員タイプと一緒にまとめられていた。このことは、知識レベルが分離する前は、それほど明らかではなかった。そのため、前述した重要なフレーズに含まれる複数の要素が、すべて同じレベルで一緒に現れていたのだ…ただ1つを除いて。
- これに気づけたのが知識レベルによって分離したからなのだ、と言われると若干疑問が残る。従業員タイプという概念が発見された段階でも、給料は変わるよねっていう発見は出来るだろうし。:+1::+1: :+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865924988896149565)
- 知識レベルという考え方は、たくさんあるモデルを整理整頓するための一つの方法のように見える。（というか責務のレイヤもそうかも） :+1:
- パソコンのフォルダの中もフォルダ分けしたり、更新順で並び替えたりすることで、目的のファイルを見つけやすくなる
- 整理技法として考えると、責務のレイヤや知識レベルに捕らわれずに、他にもいろんな観点から分離して整理することは可能になりそう
- 大規模な構造全てがたくさんあるモデルを整理整頓するための方法
- この節の例は今までよりは比較的イメージしやすかった気がする
- 「知識レベル」というアプローチは、実際にユーザーへその拡張性を公開するまでに至らなくとも、開発側・運用側で都度新規実装することなく、関連や制約を表現する値を変更・追加することで拡張・変更を実現できるという効果もあると思う:+1::+1: :+1:
- テーブル駆動設計のアプローチなどは、結果的に「知識レベル」と同じような効果をもたらすように思う
- FYI: 『[CODE COMPLETE](https://www.amazon.co.jp/dp/4891004568)』18章「テーブル駆動方式」:+1: :+1:
- そもそも自分がリフレクションをjava等の機能的(使い方?)な側面でしか捉えられていないので、内容の意味がわからない...
- Reflectionアーキテクチャパターン、POSA確認要
- ロールベースモデリングというアプローチも、ある一面ではこの「知識レベル」というアプローチを、特にアクターに対して適用した結果として見いだせる気がする
- 個別の「役職」を持つ従業員たちとは別に、さらにその従業員たちの振る舞いや制約に対するメタな知識としてのロール・権限、的な

## 疑問

- 知識レベルがあまり言語化できてないので書いてみると、●●タイプやポリシーによって振る舞いが変わるようなものを仕分けする考え方であっている？
- なぜリフレクションなのか。リフレクションでなければならなかったのか？
- なぜリフレクションなのかとは？
- enumで従業員タイプ定義して、そのenumに退職金積立制度ロジックを紐付けるようなイメージなのかな？:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865923008823820298)
- abstractのメソッドを定義しておいて、子クラスでその実装をするって意味なのかなとも思い始めた…わからん
- 知識レベルと既存のモデルの違いがわからない。知識レベルのモデルと2つ管理するってこと？:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865917880990040084)
- 知識/業務「レベル」とは？:+1::+1::+1::+1:
- (次の着脱可能…の直前)「レベルの場合、依存関係は双方向に向かう」とあるけど知識レベルから業務レベルへの依存もあるということ?:+1:
- 知識レベルの知識レベルと業務レベルが双方向に依存するという部分がいまいちピンとこなかったです。:+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865921309317529620)
- p.477

---

# 着脱可能コンポーネントのフレームワーク（PLUGGABLE COMPONENT FRAMEWORK）
## 目安の時間
- 30分

## 感想・気づき
* > p.485 **どうすれば、何千人という人々が独立して作業して、40,000パネル以上のキルトを作成ることができるのか?**
* 急に何の話かと、びっくりしたが「現実世界でもインターフェース（パネルの寸法とか材質とか）を決めて具体的な実装を移譲すると効果的だよ！」って例だったのか:+1:

## 疑問
- 話を読む限りだとtemplate methodのようなものを想像したけど、イメージあってるんだろうか？:+1::+1:

* > p483 インターフェースは正確に設計する必要がある。 抽象化されたコアを変更するには多様なコンポーネントのプロトコルを変更する必要がある。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865926447515697193)
- 結局、意図の明確なインターフェースを頑張って考えなさいということ？変更きついけど受け入れろよってことなんでしょうか？ :+1::+1::+1::+1::+1:

- 急にインターフェイスの様な実装よりな話になっているが、これって境界付けられたコンテキストをまたいだ話になるのでしょうか？

# 構造による制約をどの程度厳しくするべきか？
## 目安の時間
- 0分

## 感想・気づき

## 疑問

---

# ふさわしい構造へのリファクタリング
## 目安の時間
- 30分

## 感想・気づき

- >p.488 進化する秩序に全力で取り組むチームは、プロジェクトライフサイクルを通じて、大規模な構造について、恐れることなく再考しなければならない。
- システムの規模が大きいといきなり初手から大規模な構造を考える力が働きがちなので忘れずにいたいと思った。:+1:
- ミニマリズムのところで書いてあるのを見ると、開発初期でも責務のレイヤを取り入れることは有効っぽい？ :+1:
- > P.489 現在の配置を理解できている方が、再配置するのも容易であり、そして既存の構造があれば、現在の配置を理解しやすくなるということが挙げられる
- これは理解できるなぁ。現状のコードが実装者のメンタルモデルと合っていると、コード変更が容易だということと一緒だと思う:+1::+1::+1:

## 疑問

- > P.489 たいていのチームで交わされる類の会話だけでは、一貫性のある大規模な構造をシステム内で維持するのに十分でない。大規模な構造をプロジェクトのユビキタス言語に組み入れて、その言語を全員で執拗に鍛えることが不可欠なのだ。
- 大規模な構造をユビキタス言語に加える、というのはどういう感じだろうか。責務のレイヤの名前とかをユビキタス言語として扱う？ :+1::+1:
- ミニマリズムはXPのシンプルな設計に繋がりそうな話、メタファに続いてこれもどんな本で勉強できるんでしょう？ :+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/865933962450567178)
- アジャイル文脈の話であれば、エクストリームプログラミング第二版とか、アートオブアジャイルデベロップメントかな
- アートオブアジャイルデベロップメントは、9章のインクリメンタルな設計とアーキテクチャの話が参考になるかな、と
- 第2版はよ！

---