DDD本 15章 蒸留
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

- [2021/06/05 Sat 20:20-](https://discord.com/channels/432531367427964929/740202765619429487/850534612332576810)
- [2021/06/19 Sat 20:00-](https://discord.com/channels/432531367427964929/740202765619429487/855596988832808961)

# 自己紹介

- なかじま（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です。

---

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

## 感想・気づき

- P.406の図、サブドメインと凝集されたメカニズムは、どちらとも邪魔されない、となっている。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850697626251690014)
- 目的はどちらとも同じだけど、これら2つのパターンはどう違うんだろうな :+1::+1:
- 次回、こうご期待！

- > P.407 木を剪定して主要な枝の成長を妨げないようにする庭師のように、テクニックを一式適用することで、モデルから気を散らすものを切り落として、最も重要な部分に集中できるようにする
- これはよくわかる
- ドメイン名と持っているプロパティがそれに関連して無さそうなものだとモニョる

## 疑問

- 今までの章でも蒸留って結構出てきたと思うけど、どういうタイミングで出てきたんだっけ :+1:
- [disocord](https://discord.com/channels/432531367427964929/740202765619429487/850696121540935730)
- P.13のところで書いてある
- 4章、4部の頭と14章にある
- よりよいモデルへと昇華させていく過程の中で、不要なものが取り除かれていったり、あるいはより的確な概念へと再構築されたり、色々な処理が発生するという順序な理解
---

# コアドメイン
## 目安の時間
- 18分

## 感想・気づき
- > P.408 理解するのが難しいシステムは、変更するのも難しい
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850701921107050566)
- わかる。人間の認知の限界がある :+1::+1::+1::+1::+1::+1:
- > P.408 人は専門的にならざるを得ない。開発者が作業を特定のモジュールに限定すると、知識の伝達がさらに損なわれる:+1:
- 人が自身の認知の限界に対応する方法としての当然の策なんだろうと思った
- > P.408 現実は厳しいもので、設計のすべての部分が等しく改良されるわけではない。優先順位を設定しなければならないのだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850702501623889950)
- リファクタリングはすごくしたくなるけど、今注力すべき機能から外れたところであればやらない、とかそういう話かな
- 全ての場所をいい設計にしたい、という完璧主義者の人にとってはつらいだろうなと思います
- サブ機能だからと雑に実装され、重要じゃないからとしっかり作り直すのが後回しになる部分を見るとなんとも言えない気持ちになる。:+1::+1:
- > P.409 アプリケーションを実際に差別化してビジネスの資産とするようなモデルの部分であるのに、それほどスキルのない開発者によってまとめられることになるのが通例である。そういう開発者はデータベースの管理者と協力してデータースキーマを作成し、モデルの持つ概念の力を一切利用することなく1機能ずつコードを書く。:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850703823810986025)
- 技術的な話は好きだけど業務に関する所はあんまり人気ない気がする。そうなってくると確かに場当たり的に業務機能をつくってるかも。
- > P.409 その間、適任ではない開発者がミッションクリティカルである「ローン」モジュールを理解できないほどにもつれさせ
- ミッションクリティカルな「ローン」がコアドメインとして認識されてないから、適任ではないエンジニアを選んでしまったってことか
- もしかしたら、そのエンジニア自体はミッションクリティカルだと思われていたけど、チームとして認識されていなかったって感じなんだろうか
- > P.410 ドメインに対する洞察が経験によって深まっても、蒸留プロセスは継続できる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850702284836962335)
- むしろ継続していかないといけないのだろうと思った:+1::+1:
- > P.410 最も才能がある人をコアドメインに割り当て、そうした区分に応じて採用すること
- 最も才能がある人というのは優秀な開発者なのかな？ドメインエキスパートを割り当てることなのだろうか。文脈から、開発者が対象ドメインの知識をつけ、モデルを作ることと理解したけど、そう簡単にドメインの知識ってつかないよなと感じた。
- > p.411 プロジェクトチームにおいて技術的に最も卓越したメンバが、ドメインについて多くの知識を持っていることは滅多にない。
- 逆に、技術力の最も高い人が一番ドメイン知識もあって、その人がボトルネックになるケースも結構あるんじゃないかと思っています。そういう人はどちらかというとドメインエキスパート寄りに立って、他のメンバーが開発側。。。だろうか。

## 疑問

- > p.412 3. コアドメインについての特別な要求がない。・・・
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850698149806997514)
- 使用中のアプリケーション（業界に特化したフレームワーク）では実現できない特別な要求が出てきたときの話？？ :+1:
- よって、使用中のアプリケーションに簡単に統合できる、他のアプリケーション（特別な要求を満たせるもの）の導入を検討しているのだろうか
- 【求】日本語解読班
- > ここでの「特別な要求が無い」は、原文が You don’t have special needs in your CORE DOMAIN なので、「あなたのコアドメインに対して、何か特別な要求をあなた自身持っていない」というぐらいの訳になりそう。 この special needs が何かといえば、ドメイン特化なフレームワークの導入をどう考えるかについての話なので、コアドメインをソフトウェア上で扱う方法に対する special needs かなと。 それが無いなら、すなわちコアドメインをソフトウェア上で扱う方法について何か特殊な事情が無いなら、統合用のアプリケーションを購入するなど低リスクな方法を取れという点から、「フレームワークをわざわざ導入までしなくても、統合用のツールがあれば十分じゃないの？」というお話なのかなーと理解。
- > 3．は、「コアドメインは特定できているけれど、コアドメインに自分たち独自の要求がないから、一般化された製品/ライブラリを持ってきてそれをそのまま使うというのが選択肢になりえる」ということをいっているだけかと。つくるまでもない。

---

# 蒸留の拡大
## 目安の時間
- 18分

## 感想・気づき

## 疑問

- > P.412 強調されたコアは、コミュニケーションを改善して、意思決定をしやすくなる。ただし、それでも設計はほとんど変更しなくてよいか、あるいは全く変更する必要がない
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850705123683729490)
- 設計を変更する必要がない、というのはどういうことだろう？:+1:
- 次回、こうご期待！

---

# 汎用サブドメイン（GENERIC SUBDOMAIN）
## 目安の時間
- 18分

## 感想・気づき

- コアドメインを見つけよう、そこに集中しようという言葉はよく聞いていて納得していたが、汎用サブドメインという名前を付ける意味として、コアと「コアではないもの」を区別したいという欲求があったからなんだろうと思った:+1:

- p.419あたり(「汎用とは再利用可能という意味ではない」の直前)我々技術系の人間は、タイムゾーン変換のような限定可能な問題を楽しむ傾向があり、そういう問題に時間を費すことをたやすく正当化してしまう
- とてもよく分かる。技術的に難しかったりするところ(認証やDB周り)を優秀な人がずっとやっていてコアの方は大してやっていなかったりする
- あるテーマについて、「わかりにくい」とか「難しい」という理由で、「限定可能な問題」であるかのように強引に落とし込もうとする動きも、よくある気がする

## 疑問

> p.420（『汎用とは再利用可能という意味ではない』節の最終行）
> 第二のより重要な理由は、そうした業界に特化した概念はコアドメインに属するか、独自の特殊なサブドメインに属するかのいずれかであり、こうした特別なモデルは汎用的なモデルよりも価値があるということだ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850705648168861696)
- 汎用サブドメインに、業界に特化した概念モデルを導入できるなら、それはコアドメインor独自の特殊なサブドメインだから、汎用サブドメインじゃないでしょ。ちゃんと汎用的な範囲に収めなさいという警告として捉えたら良いのだろうか？ :+1:
- 余談で「独自の特殊なサブドメイン」ってなんだろうと思った :+1::+1::+1:
- 自分も例がほしいなと思いました
- ちょっと間違ってるかもしれなくて恐怖ですが...
- 例えば、R市場というマーケットプレイス型のECだと、商品を出品する店舗が自分たちが許容する配送業者と決済手段を選べるんですね。店舗Aではこの配送業者が使えて、店舗Bではその配送業者は使えないみたいなことがあります。なので注文プロセスでは、その商品が対応できる配送業者を理解して、配送料金テーブルを適用する必要がありました。
- で、コアドメインというと配送料金計算を含む注文を確定するプロセスで、注文商品金額を求めるために商品金額を合計して -> クーポンによる値引き -> 配送料金計算 -> 決済手数料計算 -> Rポイント付与計算、が大変でした。ここを間違いなく最も優秀なエンジニアが担当してました。
- この中において、配送料金は結局配送業者が決めてるところがあるので、一般的な配送料金の仕様を取り入れるだけ、になります。これは一般化された製品/ライブラリを持ってきて導入にはなることもあったり、あるいは公表されている設計(料金表)に従って実装されることもしてました。その後結局プラットフォームがボリュームディスカウントを効かせるので、自前で書いてました。この配送料金計算とかは、「独自の特殊なサブドメイン」だったのかなあと今は思います。:+1:

---

# ドメインビジョン声明文（DOMAIN VISION STATEMENT）
## 目安の時間
- 18分

## 感想・気づき

- > また、ドメインモデルの重要な側面は、複数の境界づけられたコンテキストにまたがることもあるが、これら別々のモデルはその定義上、共通の焦点を示すような構造にはできない。
- 全体の統一したビジョンがあるというのに重要さを感じる一方、最後に「通常、橋渡しが必要になる...」とあるあたり、現実これでも不十分という悩みを感じる。
- インセプションデッキとかで作られるアプリケーションの意義とかというより、モデルに含めるべきものと含めないものを表明している感じなんだろうか:+1:
- > これは重要であるが、ドメインビジョン声明文の一部ではない
- 最初から見た目や使い勝手の議論は、非エンジニアを交えて会話した時でも結構あり、かつ本人にその意識がないことが多く悩ましい。こうして、比較型で話すのが伝わりやすいのだろうと思う。

## 疑問

- > P.422 多くのプロジェクトチームは、管理のために「ビジョン声明文」を作成する
- これって、今だとインセプションデッキ（エレベーターピッチ、パッケージデザイン）などになるのかな

- ドメインビジョン声明文を実際に作っている現場ってありますか？ :+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/850712591436742667)

---

# ============================= 6/19 後半はここから ================================

# 強調されたコア（HIGHLIGHTED CORE）
## 目安の時間
- 18分

## 感想・気づき

- > P.424 チームメンバがコアドメインの構成をおおまかに知っているとしても、別の人々が全く同じ要素を拾い上げることはなく、同じ人であってさえも日によって変わるものだ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855791076941234217)
- 「同じ人でさえ日によって」というところは常に意識したい。視覚化しておかないと、わかりやすいケースだと各論に入った時に色々な情報を見失う。:+1::+1::+1::+1::+1::+1::+1::+1:
- どれがコアドメインなのか、というのを分かりやすくしたい。だけど、汎用サブドメインで切り分けてモジュールによってコードでいきなり示すには大胆過ぎる（たぶん、誰かに止められる？）から、このパターンをまずは使うといいよ。という感じに読み取れた。
- 蒸留ドキュメントを作成することで、コアドメインがどこかを認識できるのは納得。非技術系のメンバも理解できるようなドキュメントを書くのもわかる。ついつい、開発者しかわからないドキュメントを作ってしまいがちなので。:+1::+1::+1::+1:
- >ドキュメントを独立させることに伴う通常のリスクは、ここにも該当する。
- エントリ用に、わかるドキュメントを別建てで用意したいのも納得するし、ここでいう「ドキュメントが維持されないかもしれない」も納得。悩ましい。「ミニマリズムに徹する」、詳細に入らないことで見ようと思う、直そうと思えるのが肝なのか。:+1::+1::+1::+1:
- モデルはドキュメントじゃないよ、みたいな趣旨の話を第一部あたりでしていたけど、このあたりはガッツリ、ドキュメントって言っているんだなぁって思った

## 疑問

- > P.424 コードの構造を著しく変更することは、コアドメインを識別するための理想的な方法だが、短期的に見ると、必ずしも実用的と限らない。:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855772881338368010)
- では長期的に見ると実用的ということ？
- 「長期的な視点 -> 実用的」は「短期的な視点 -> 必ずしも実用的ではない」対する裏なので(=対偶ではないので)、この説明だけではなんとも言えないように思う:+1::+1:
- 「理想的な方法」が理想的であることと、それがある視点から実用的と評価できるかどうかは別の話なので、「長期的な視点から見ても実用的ではない」と評価することは可能
- 理想的な方法を紹介し、逆接で繋いでいることにも意味はある気がします。
- 理想とあるので、ここでの理想が嫌味でなければ、実用的なのだと思います。
- > P.425 中心的な抽象とその相互作用に集中すれば、ドキュメントが古くなるのを遅らせることができる。そのレベルのモデルは安定しているのが普通だからだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855770615829889034)
- コアドメイン内部の要素は安定しているのが普通だ、と言っているように聞こえるが、果たして本当にそうなんだろうか？　深いモデルを見つけた時のように、暗黙的な概念が見つかってモデルが変わることは充分にあり得ると思っている。:+1::+1::+1::+1::+1:
- ここで言っているのは、あくまで抽象的に書けば詳細の変更によってドキュメントが古く見えるのを防止してるくらいの感覚でした。書かれているようなモデルのリファクタが発生したら、古くなるのだと思います。:+1:
- ここで言っているのは違うことなんだろうか？
- コアドメイン内部の「中心的な抽象とその相互作用」は「詳細」よりも比較的安定している、と言えると思う。「中心的な抽象とその相互作用」が変更されないとは書かれていない。:+1:
- :memo: 実装的な詳細に踏み込まずに、ドメイン知識を理解するに足る程度の抽象度のドキュメントであれば、影響されにくいとか、という感じと理解してます。
- :memo: 見いだされたモデルを元に、ある程度演繹的に書き下していく形で済む範囲内では安定するだろうけれど、 他方で有る種のパラダイムシフト的な現象が発生した場合には、そもそもの根本であるモデルに影響が及ぶのは自然ですし、それを回避しようとするのはまた危険なにおいに感じる。
- > P.426 モデルの主要なリポジトリ内においてコアドメインの各要素にフラグを立てること。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855769917148102686)
- 「フラグを立てる」とは具体的にはどういうこと？前の段落にあるように例えばコアドメインのクラスにコメントを書くみたいなこと？:+1::+1::+1::+1::+1::+1:

---

# 凝集されたメカニズム（COHESIVE MECHANISMS）
## 目安の時間
- 18分

## 感想・気づき

- P429 「概念的な「何か」が、機械的な「どのように」によって浸食されてしまうのだ。」メソッドが多すぎ、ということを表現ということなのだろうが、モデル(クラス)は概念で、処理(メソッド)は機械的なんだから、概念を大事にしなよということを伝えているのかな？
- P.430の例15.2を読んでいると、組織図に関するものはコアドメイン。それを検索したり辿ったりするHowの部分は形式主義であるグラフである → 凝集されたメカニズムってことだと読み取れた。
- ある意味汎用サブドメインの一部のように見えるけど、どうなんだろう？:+1:
- 違うのだろうが、「凝集されたメカニズム＝アプリケーションサービス」のようなイメージが付いている。ドメインとは違う処理群のようなイメージなので。:+1:
- 汎用サブドメインの例として「認証機能」が取り上げられるイメージがあるが、実務的には認証の概念が無く、アプリ利用の為だけの認証なのであれば、汎用サブドメインではなく、凝集されたメカニズムの方が自分の中のイメージに近い。

## 疑問

- 凝集されたメカニズムは、フレームワークとして閉じ込めるとあるが、具体的なコードで考えたときにどこの層に閉じ込めることになる？:+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855774870440116244)
- :memo: p. 429 このような分離されたメカニズムは補助的な役割に置かれ、後に残される小さく表現力 豊かになったコアドメインは、以前よりも宣言的なスタイルになったインタフェース経由 でそのメカニズムを使用する。
- > 特に、形式主義や十分にドキュメント化された種類のアルゴリズムに気を配ること。
- ここでの「形式主義」 is 何？
- 原文では `formalism`
- 前にも「形式主義」という訳見かけた記憶がある（本来の意味ではなく、字面のイメージで語や訳をあてたんじゃないか疑惑が発生した記憶）:+1:
- 辞書的な [formalism](https://www.oxfordlearnersdictionaries.com/definition/english/formalism?q=formalism)
- 過去のあたり
- https://discord.com/channels/432531367427964929/740202765619429487/817740553710075954
- https://discord.com/channels/432531367427964929/740202765619429487/817743379592773672
- https://discord.com/channels/432531367427964929/740202765619429487/817743964115304459
- > これはまさしく、よく発達した形式主義であるグラフ(graph)によって解決される種類の問題である
- ひょっとして、formalism = 「形式、形式化された」ぐらいの意味で使ってる?（困る……)

---

# 隔離されたコア（SEGREGATED CORE）
## 目安の時間
- 18分

## 感想・気づき

- ドメイン声明ビジョンで重要となるモデルの方向性を示した後、強調されたコアで、多くのモデルからコアドメインを強調した後、コア内部の不純物（あまり関係ないモデル）を取り除く活動が、この隔離されたコア、という読み方をした。
- なので前提としてコアになるモデルを発見していることが前提っぽい:+1::+1::+1:
- 章の最後にある「リファクタリング対象を選ぶ」にも繋がりそうな話:+1:
- このリファクタリングはテストコードを書くのも大変そう
- 敢えて詳細に触れないようにする考え方が好き。なんでもかんでも詰め込めようとして理解しづらくなっているドキュメントはあるある。

## 疑問

- 「隔離されたコア」はソフトウェアの肝の部分がモデリングされた、いわゆる「コアドメイン」と考えてしまってよい？それとももう少し広い概念？:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855779311196569601)
- 逆に「隔離されていないコア」は存在しうるだろうか？この章の図の例ではリファクタリングによって「配送」というコアを隔離したが、リファクタリング前の状態を隔離されていないコアとは呼ばない（呼べない）のだろうか？
- 別の表現をするといわゆる「コアドメイン」は隔離されているものという前提が常に存在しているとみなしてしまってよいのだろうか？
- 特に言及されていた印象も無いので、単純に呼べると思っていましたが、呼べないかもと感じた理由があれば気になります。

---

# 抽象化されたコア（ABSTRACT CORE）
## 目安の時間
- 18分

## 感想・気づき

- > P.441 別々のモジュールに置かれたサブドメインの間で大量の相互作用があると、モジュール間で多数の参照を生成する必要が生じて、分割したことの価値をほとんどなくしてしまうか、相互作用を間接的に行わなければならなくなって、モデルがあいまいになるかのいずれかである
- とてもわかる。こういう兆候が見られたら、モデルを見直すサインなのかも:+1:
- 抽象化されたコアのイメージがつかない:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855786577409474570)
- 括り出されたインターフェース名やメソッド名と、ドキュメントで使用されている用語が完全一致している世界に行ってみたい。:+1:
- ここら辺の話、上手く言語化できないけど、CleanArchitectureの話に近そう。:+1::+1:

## 疑問
- > P.442 分割する線を垂直にではなく、水平に引くことを検討すること。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855784081757569055)
- 分割する対象はモジュール？
- 「垂直にではなく、水平に」とは具体的にどういうこと？後に続く文章的には多態を利用するのが水平？:+1::+1::+1::+1::+1::+1:
- :memo: 水平は抽象度の違い 垂直は対象領域の違い

---

# 深いモデルの蒸留
## 目安の時間
- 9分

## 感想・気づき

## 疑問
- > P.443 深いモデルを生み出すブレイクスルーはどこで発生しても価値を生むが、プロジェクト全体の軌道を変えられるのは、それがコアドメインにおいて発生したときだけだ。:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/855788722196316180)
- ということは深いモデル＝コアドメインとは限らないということだよね？
- 深いモデルとコアドメインの差分はどこにある？モデルとして洗練されていてもアプリケーションが解決したいコアな問題解決に直結するとは限らないからということ？
- 深いモデルとコアドメインは、そもそも比較するものではないのかなと思いました。深いモデルは、ドメインに対する「洞察の鋭さ」の度合いの話。比較するのであれば、深いモデルと浅いモデル（こんな用語出てきてないが）。コアドメインは、事業価値の度合いの話。コアドメイン、支援サブドメイン等。事業としての価値が低いドメインにおいて、鋭い洞察が得られている（＝支援サブドメインの深いモデル）ケースもあると解釈してます。:+1::+1::+1::+1:

---

# リファクタリング対象を選ぶ
## 目安の時間
- 9分

## 感想・気づき

- リファクタリングの対象を選ぶ時に、自分では2の方針を選ぶことが多かった。でもそれが費用対効果を大きく生むかという観点では足りなかったのかもしれない。:+1:

## 疑問

- コアドメインが見いだせていないときのリファクタリングの対象はどうやって選ぶのだろう？:+1:

---