DDD本 1章：知識をかみ砕く
===
###### tags: `エヴァンス本読書会`

https://ddd-community-jp.connpass.com/event/185933/

# Discord開始位置

- https://discordapp.com/channels/432531367427964929/740202765619429487/746684770863284254

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントとかするなりしてもらって大丈夫です
- 聞いているだけの方もOKです

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブルhttps://hackmd.io/MboOYVJGS-CrnU_WQQ1nAg#

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:05 | 5分 | 当日の流れとグランドルールの共有 | |
| 20:05-20:15 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:15-21:55 | 100分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

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

---

# 第1部 ドメインモデルを機能させる
## 目安の時間
- 15分

## 感想・気づき
- 18世紀の中国の地図みたいに、「自分たちにとって関心のあるように表現した地図」がモデルだということを、ここでは言っているんだろうなぁと思った :+1: :+1:
- 地図のメタファ、読む度にこれ以上の題材無いんじゃないかと思う
- 電車の路線図なんかも「地図」の一種と言えるよね、とか思いました。
- P.2の「当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって」と書かれているのは、かつてオブジェクト指向が出てきたときの現実世界をそのままコードに表せる、といった話とはだいぶ違うなぁ。:+1: :+1: :+1:
- むしろそんなことが広まって失敗したから、こういう話が出てきたのかな？ :+1:
- P.3「ドメインモデリングはむしろ映画製作に近く、ある目的に従って、現実の概要を表現している」というのには、なるほど、と思った。あまり重要ではないシーンはカットするという考え方。:+1:
- 当時の中国の地図に対し、「現代の中国には全く無意味だろう。」と書かれていることが、まさにドメインモデルを磨く必要性を表してると感じた。 :+1:
- :memo: 現代の中華人民共和国と当時の清国とで、「地図」に対する関心事が違っているというお話（で、モデルの更新とはちょっと違いそう）に感じた
- モデルの3つの基本用法の2つ目に 「モデルは、チームメンバ全員が使用する言語の基盤である。」とある。ドメインモデルへの意識の弱いチームがユビキタス言語を意識せずに表記揺れを頻発してしまっている状況に何度か遭遇したことがあるが、基盤が無いのだから言語もブレて当然なのだとしっくりきた :+1: :+1: :+1:
- (逆に言うと、表記揺れを見つけたらチームがドメインモデルを理解していないことのサイン？)。
- P.4 「有能な開発者のほとんどは、自分の手掛ける特定のドメインについて勉強する気があまりなく、ドメインモデリングのスキルを真剣に伸ばすつもりはさらにない。」が心に刺さった。DDD関連のスキルを定量的に評価できないから、転職が盛んなエンジニア界隈でドメインモデリングを勉強するメリットが薄い。どうにかしてこの流れを変えていきたいですね。:+1::+1::+1::+1::+1::+1:
- 全体として、ドメインやモデルの意義、そしてソフトウェアの目的と求められる開発者の姿勢が整理されていて、概念の理解と共に、エンジニアという仕事を深い部分での理解も進んだと思う :+1: :+1:
- P3 「ドメインモデルとは特定の図ではなく、図が伝えようとしている考え方である」から、特定のセオリーによって積み上げるものではなく、合意形成の考え方と考えるといいと感じた。だからこそ、難しい概念なのだと。
- p2,3 ドメインとは「プログラムを適用する...対象領域」で、モデルとは「簡素化...選び抜かれて抽象化された...１つの解釈...知識の表現形式である」ことからドメインモデルとは、プログラムを適用する対象領域の知識を洗練し/削ぎ落とし/抽象化した解釈や表現、であるから深い洞察や探究が必要であると思った。
- p.3 「モデルとは、選びぬかれてシンプルにされ、 **意図的に組み立てられた** 知識の表現形式である」 :+1::+1:
- モデルは予め存在するものではなく、モデルを使う人々が **意図的に** 組み立てる必要があるもの :+1::+1: :+1::+1:
- なので、現実世界の言葉をそのまま抜き出せば良いのではなく（それは「選びぬかれ」ただけ）、さらにシンプルにし、再構築する必要がある
- そしてどんなモデルも、現実の何らかの側面や興味の対象となる概念を表している。モデルとは簡素化である。
- 事実は一つだが、解釈は無限にある。モデルとは、自分たちの解釈を表現したものだと思いました。:+1:
- ユーザの活動において有効利用されるソフトウェアを作成するために、開発チームはその活動に関係する体系化された知識を身につけていかなければならない。:+1:
- 人を雇う時、技術のみに興味がある人だと開発チームとして機能しないのかも:+1:
- ユーザの活動において有効利用されるソフトウェアを作成するために、開発チームはその活動に関係する体系化された知識を身につけていかなければならない。
- 細部を切り捨てることで、伝えたいことを明確にする。モデリングとは、取捨選択であると言い換えられると思った。:+1:
- ドメインモデル
＝ドメイン知識の獲得と支配のためのツール
＝図が伝える考え方
＝知識が厳密に構成され選び抜かれて抽象化されたもの

## 疑問

- P.3〜4の「3.モデルとは、蒸留された知識である」の、蒸留とは？　第15章のはじめや、P.13を見ていると、不要な概念を省いていく工程のことを言っている？:+1:

- P.3のモデルと実装が結びつくという部分がイメージわかないのですが、これは適切なモデルをちゃんとコードに落とし込んだものという認識なのでしょうか？

- P5.「チームのリーダがドメインの中心に何があるのかを理解していれば、...」に関連して、チームを複数に分割したアジャイル開発のときには、どうやって全体を見たモデリングをしたらよいのでしょうか？リーダにモデリングの知識がないと、どんどんソフトウェアが腐敗していくように思いました:+1: :+1: :+1: :+1:
- :pencil:チームの分割、「分担並行すれば効率()良いよね」的な発想で安易に行われると危険そう
- :pencil:本書後半の境界づけられたコンテクストが参考になると思います

- p2. 「モデルとは、選び抜かれてシンプルにされ、意図的に組み立てられた知識の表現形式である」→自分で設計する時も、シンプルにしなきゃと思いつつなんか複雑化しているような疑問に駆られてしまう。皆さんは「シンプルなモデル」についてどんなイメージなのか気になります。:+1: :+1: :+1: :+1::+1: :+1: :+1::+1::+1: :+1: :+1:
- :pencil: シンプル＞本質的課題を捉えて、その課題を解決するために無駄な要素がないことを表現したもの
- :pencil:Kent Beckが「シンプル」の定義に「意図が明確である」を含めている、というのが足がかりになりそう
- :pencil:シンプルとは少なさのこと。必要十分であり、無駄なことをしていない。曖昧さもない。
- :pencil:適切な抽象化
- :pencil:何回も絵に書けるくらい
- :pencil:断捨離が上手い人は得意そう
- :pencil:https://martinfowler.com/bliki/BeckDesignRules.html
- :pencil:画期的な製品開発には無駄を省いた「マイナス思考」が活かされている、とよく見かけるけど、ドメインモデリングにも無駄を削る「マイナス思考」が必要なのかも。
- :pencil:自分はシンプルと思ってても、他の人から見たら複雑とかある気がする

- 「ソフトウェアの核心」にドメイン設計という言葉が出てくるが、どういう意味？　ソフトウェア設計のこと？　問題解決する領域の範囲を線引きすること？　業務を再定義すること？
- :pencil:「ドメイン = ユーザーの関心事や活動」なので、私達（ユーザー、開発者、ステークホルダ各種）が何に関心を持ち、どんな活動を行うかを整理し、線引することが、ここで言う「ドメイン設計」なのかなーみたいなイメージ
- :pencil:有る種の業務設計とも言えるし、いかに「世界」を認識し、いかに「世界」を区切るかを考える活動とも言えそう:+1:
- :pencil:ドメインを分析して、ドメインのあるべき姿を設計するということ。
- :pencil:ドメイン設計は、ドメイン駆動設計でなくても必要だと思ってます
- :pencil:ドメインモデリングによりドメインを俯瞰して、現実のドメインを設計し反映したりするイメージ
- :pencil:ドメイン設計のいち手法がドメインモデリングかなー、的なイメージです
- :pencil:ドメイン≠ビジネス、ということですかね
- :pencil:ドメイン自体を変える意味じゃないけど、
- :pencil:ドメインから設計 -> 計画、策定、図案する
- :pencil:ソフトウェアの対象領域を切り出し、その領域の中身の認識を深めていくことですかね

---

# 第1章 知識をかみ砕く
## 目安の時間
- 15分

## 感想・気づき
- P.8「彼らはしきりに私の言うことを訂正し、それによって私にも知識が身につき始めた」が、間違い前提でモデリングをして、それを元に議論する感覚なのかと思った:+1: :+1: :+1:
- P.9のプローブシミュレーションの機能だけに絞った話は、ユースケースのスコープを絞っているんだろうと思った
- P.12の永続化とUIを省いて、ふるまいだけに集中するというのは、とても大事:+1: :+1: :+1: :+1: :+1:
- その領域に長いこといると専門用語とその領域特有の用語の区別がつかなくなってくると感じる
- 外部と交流する、新しい人を常に受けいれ続けるのは大切だと思った
- 後にも続くが、コミュニケーションがユビキタス言語とドメインモデルを蒸留する唯一の方法だと思った
- P.12 ドメインエキスパートと議論してモデルの図を作って終わりにせず、実際にプロトタイプを作って動くソフトウェアとしてフィードバックをもらっているのがとても重要だと思った。 :+1: :+1: :+1:
- 「コンソールキック」でも、テスト実行でもいいから「実際に(擬似的にでも)動くコードを作る」というのがいいんだろうなと(実際は自分は徹底出来てないけれども)それこそが「モデル」と呼ぶべきものなんだろと。 :+1:

## 疑問

- 「ドメインエキスパートとのヒアリングの内容をそのまま実装する誘惑」にはどうやって打ち勝っていますか?:+1: :+1: :+1:
- :pencil: 言われたことを噛み砕いたりせずに実装ということ
- :pencil: 保守で後々自分に負担がかかるかもという心理が誘惑に打ち勝ちます
- :pencil: 「ドメイン = ユーザーの関心事」を考えるにあたり、what(問題領域)とhow(解決領域)の区別を持ち込むの、有力な気がします
- :pencil: すっとぼけながら「なんのためにやってます？」と投げかける訳を作る
- :pencil: 会話しかないなー。理解できないところとか、矛盾の有る部分とか、そうなっている理由を腑に落ちるまで聞かないと厳しい
- :pencil:「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」ヘンリー・フォード
- PCBの例は理解が難しいように思ったのですが皆さんどうなのでしょうか？

---

# 効果的なモデリングの要素
## 目安の時間
- 15分

## 感想・気づき
- チーム開発の場合、ドメインエキスパートとのやり取りから得たモデルの概念をチームに落とし込むのに苦戦しそうですね :+1:
- 「モデルを蒸留する」には、役に立たない・確信(核心?)でないと分かった概念を取り除くことも大事というのが気づきだった これはこの本で取り扱っている「ドメイン」という言葉自体が、"ユーザーの活動・関心のうち、プログラムを適応する領域 = ソフトウェアのドメイン"ということにもつながってくるなと思った:+1: :+1::+1::+1:
- リモート主軸の昨今で、このような抽象度の高いコミュニケーションをどうやっていくかが課題になりそうだなと思った:+1: :+1:
- :pencil: リモートホワイトボードが欲しいですね。
- :pencil: アイコンタクトと微妙そうな表情がないのがきつい
- :pencil: ノンバーバルなコミュニケーションができないという話かな？
- :pencil: コミュニケーションの帯域が足りない。表情とか反応速度とか
- 一昔前かつ現場限定、かもしれないが「概念モデル図と実装モデル図」みたいな概念でやってたが、ここでは「モデル(図とも呼んでない)」一つでやってくし、全員が「真ん中に置いてる」ことが重要なんだなーと :point_left:
- とりあえず書き出すことで、何が違って何がわかってないのかを議論できた
なんか、真のアジャイルってこういうことかって感じする。
たった一つのことだけに集中していて、それができることで次に進む。
私が、新しく獲得した知識をどのようにモデルとソフトウェアに組み込んでいくのかをクライアントが理解したからである。しかも彼らは自身の考えを評価するための具体的なフィードバックを私が作成したプロトタイプから得ていたのである。
それによって、ドメインの知識が組み込まれたモデルができたし、言葉のズレが減った

## 疑問

---

# 知識のかみ砕き
## 目安の時間
- 15分https://hackmd.io/MboOYVJGS-CrnU_WQQ1nAg?both#

## 感想・気づき
- P.14「知識のかみ砕きは独りで行う作業ではない。開発者とドメインエキスパートが・・・・たいていは開発者が率いる」→ドメインエキスパートが複数人いて、意見が割れた時に落とし所を見つける能力もエンジニアとして必要なんだろうなと解釈した。 :+1: :+1:
- :pencil:前者は、エンジニア的な観点から、整合性のあるモデルを提示するとか、そもそも同じ言葉を使っているけれど違うものについて語っていることを明らかにするとか、そういう動きが求められるかなー。
- :pencil:エキスパートにまとめてもらってました
- :pencil:両方を呼ぶ
- :pencil:一堂に会して議論をして、伝書鳩を避けたい。
- :pencil:意見が割れるなら、それはシステムとして方向が定まっていないと思うので、開発者的には「じゃあ、一旦そこは後で交換可能にしておきますので」で収めて、実装しつつまた相談してね聞かせてね、をよくやってます
- 意見が割れるからこそ、重要ではない可能性高い。
- P.14「知識のかみ砕きは独りで行う作業ではない。開発者とドメインエキスパートからなるチームが共同して行うもので、たいていは開発者が率いる」の部分、取引先の担当者に権限がなかったり、担当者が実務を担当している人を引き出せないパターンが多すぎて実現出来ないことばかり。そういう際の方法論やテクニックとかを纏めたような資料などがほしい。 :+1: :+1:
- :pencil:来てもらうより行くしかないですよ
- :pencil:「俺が行く」って言いたいけど言ったことはない（根性なし）
- P.15「プログラマがドメインに興味を持っていなければ、プログラマはアプリケーションが何をすべきかだけを調べ、その背後にある原理には注意を払わない。」の言葉のままになっていないか不安になった。自主性が育まれないようなチームだと、こうしてソフトウェアが使えなくなっていくんだろうな :+1:
- 「ドメインモデルを機能させる」でもあったが、ドメイン駆動な開発は、技術にのみ関心をもつ技術者では成立しないということを説明しているなと思った:+1: :+1: :+1:
- 「**知識を噛み砕き、本当に重要なものを明らかにしてくれるシンプルな解を見つける**」あれこれ考えて重厚長大なアーキテクチャにしがちだなと思った:+1:
- やはり「DEはドメインを知ってれば良い」けど「プログラマはプログラムに最大の注意を払いつつ、ドメインに”興味”を持たねばならぬ」という「オールマイティ」求められてるので、「なんちゃって」じゃなく「そのハナシなら何杯でもイケる」くらい興味持てないと(嫌いなものに対しては)出来ないよなーと。
- 「コードは納品されても知識は付いてこない」「知識が失われてしまう」を「できるだけ抑える」ためにも、「モデルが知識の集積場(モデル見たら業務が解る)」を目指すんだなと。
- 「やってくうちにコアではないと解ったから、その部分を捨てた」というエピソードは「コアに注目なさい」「不要な物は捨てなさい」という啓蒙に感じた。(サンクコスト/コンコルド効果に囚われなさんなと)

## 疑問
- 始めからClean Architectureみたいな実装しないイメージであっていますか? :+1:
- レイヤードアーキテクチャ→…→Clean Architectureって成長させる感じ?
- :pencil: 要求レベルなのか、実装レベルなのかで観点が異なるイメージです。要求レベルの段階では実装レベルのアーキテクチャーはあまり関心どころではないかと思います。
- :pencil:ドメインのアクティビティをまず理解しようとするフェーズなので、レイヤー化アーキテクチャやClean Architectureはその後のプロセスではないでしょうか。Ericさん曰く知識のかみ砕きの具体的なプロセスは[Whirlpool](https://domainlanguage.com/ddd/whirlpool/)だそうです。一つの参考になると思いますし、今ならEvent StormingやICONIXなど様々な分析方法があるので参考にできると思います。
- :pencil:Ericさんのお勧めはその方法らしいです
- ドメインだけを取り出すやつ
- :pencil:初期からドメインオブジェクトだけをテストコード上で会話させるのも設計のやり方ですよね
- :pencil:いったん、実装を忘れるのだ

---

# 継続的学習
## 目安の時間
- 15分

## 感想・気づき
- P.16 冒頭の「ソフトウェアを書き始めるとき、我々は対象を十分理解しているわけではない。」という言葉は重い。:+1::+1: :+1: :+1:
- この点は理解しているつもりなのに、ついつい最初から机上で完璧なモデリングを作ろうとして時間をかけすぎてしまう。
- P.17「発見の旅は、どこかから始めなければならないのだ。」の言葉から勇気をもらえた。今のチームにモデリングの文化がなくても、自分一人が簡単なところから始めることで、徐々にソフトウェア全体が良くなっていくように思えた:+1:
- P.16「高度に生産的なチームは、自分たちの知識を意識的に育てて継続的学習を実践する。」→毎日行うKPTとかに組み込んで、ドメイン知識に関する疑問を解決できたらいいのかなぁ？？（Problemに理解できていないドメイン知識を埋め込んでいくみたいな）
- アジャイルだなという印象

## 疑問
- 「典型的なアプローチの場合、・・・口頭での伝承が何らかの理由で途切れたら、知識は失われてしまう」と知識の流出について記載されている。高度に生産的なチームもプロジェクトもプロジェクト中はメンバが学習し、知識が蓄積されると思うが、終わると知識が散在するように見えた。プロジェクト(作ったもの)に知識を残しておくにはどうするのかというのがよくわからなかった。(あとの章に記載があるのかも知れませんが):+1::+1::+1:
- :pencil:戦術的DDDで実装されていれば、少なくともコードはドメイン知識を語ってくれるはず
- :pencil:ドキュメンテーションだけしても結局読まないですよね。
- :pencil:チームも成果物なので、チームを解体するのは成果を欠損させることになってしまうのですよね
- 意図や歴史を（口頭でも）伝承できる人を増やす、絶やさないという方向もあったりしますよね
- SECIの暗黙知形式知のサイクルですよね
- :pencil:コミットログには Why と言ったのはそのコミットの意図なので、設計の意図はハイレベルなドキュメントにかきたいで
- :pencil:Architectural Decision Records=ADRとかよさそう
- ADRはドメイン知識の継承とはちょっと違うのかなと思ったんですが。
- ハイコンテキストな設計は残せない？
- :pencil:Design Doc とか
- :pencil:コードからリバースするような設計はやめよう
- Computer scienceでなく、例えば歴史学とかの領域でのbest practiceとか興味あります
- こうした「ドキュメント減らそう」というのは、継続可能、発展可能にするためにそうするのであって、「ドキュメント減らそう」だけが独り歩きすると「ソースが仕様書」が生まれるのかな、など
- 新規開発のモデリングはどこまでやるか悩み中です。みなさんはどれくらいやります? :+1: :+1: :+1:
- 「答えはない。だから、PoCや実験」勢が大半だとやりにくい
- (個人的には)DDDとアジャイルは親和性があるので、実装する前に実装内容は固めたい
- [DDDをScrumで廻す あるいは ScrumをDDDで廻す](https://www.slideshare.net/kiroh/dddscrum-scrumddd)が参考になったので、似たような方法で実践しています。理想は果てしないので、スプリントにおけるゴールを仮決めして進めるといいのではないでしょうか。スプリントより細かい粒度であるタスクでは、TDDのようなアプローチを取り入れることで、安全にドメインモデルの設計を見直しながら進めることもできると思います。大きな理想は完了することが難しくなるので、まず着地できるゴールを作って、段階的に理想に近づきたいところです。

---

# 知識豊富な設計
## 目安の時間
- 15分

## 感想・気づき

- P.18 「オーバーブッキングポリシー」は、普通に手続き型で書いていると中々思いつかない方法だと思う。こうやって手続きを知識として形にするのって滅茶苦茶大事なことだと思う。:+1::+1::+1:
- P.20の明示的な設計の利点を読んでいると、「明示的な設計」はわかりにくい計算式に名前を付けること。単なる変数ではなく、型というモジュール構造にして抽象化をすることなんだと思える
- P.20「こうした手の込んだ設計をドメインのあらゆる詳細に適用することを推奨しているわけではない。」が初学者の私に重要なことを教えてくれた。習いたての知識を使いたくて全てにやろうとしても、時間がかかり、かつ分かりにくくなる。結果としてチームメンバから煙たがれて、モデリングが進まなくなるから、重要なところだけを進めていく必要があると気づいた :+1: :+1::+1:
- 例1.1の前の部分、「通常、ドメインエキスパートは～矛盾を調整し、常識で考えて隔たりを埋めている。だが、こういうことはソフトウェアにはできない。」そもそも業務をまるごとシステム化することは不可能であることに気づいた。その不可能部分を摘出し、対処するために知識が必要であると思った。
- ルールや制約を処理の中に埋もれさせてしまうのではなく切り出すことが大切であると感じた。いきなりドメインの重要な知識を抽象化させるのは困難なので、まずは明らかな制約を切り出すことでその中で重要なものとそうでないものを選択できるのだと思った。:+1:
- p.20「手の込んだ設計をドメインのあらゆる詳細に適用することを奨励しているわけでではない」:+1:
- これはコアドメインに集中することの大事さを言っていると考える。:+1:
- 開発リソースは有限。限り有るリソースの中で、価値を生み出すところの設計品質を向上することが肝要だ、ということを訴えていると考える。
- オーバブッキングポリシーの例から、要件の本質を抽出することとその抽出物をコード（成果物）に落とし込むことでドメインエキスパートにフィードバックを位受けることができる環境を作れることがわかる。
つまり、この環境は、待っていてもできるものではなく、開発者側から積極的に作る必要があるということがわかる。
表層にあり、それらしいものを捨てた時か、違う視点で見たときに問題の核心をつくような抽象が発現する。

## 疑問
- ドメインエキスパートにコードを見せていますか？ 読んでもらえますか？
- :pencil:VBA やってる人がいたとき、システム開発の知識ある人がいたとき、見てもらえた
- :pencil:POを加えてドメインモデリングしたことはある
- :pencil:コードは読めない方が多かったので、基本は図で会話でしたね。
- :pencil:コードを見せる必要はないのではないかなー。モデル図レベルで充分。
- :pencil:稀にあるけど、基本はモデルで会話してます
- その場合も、ちょうど手元に有ったのがコードだったのでそっち使っただけで、コードを使う積極的な目的は無かったです
- :pencil:図も、抽象的なクラス図や ER図はお客様には理解が難しくて、具体的なオブジェクト図とかコラボレーション図が重宝しました
- :pencil:実装は見せたことないけど、抽象は見せたことあります。抽象はドメイン固有型の定義部分のみですね。モデル図でコミュニケーションすることが多いかな
- :pencil:Chenの (大元の) ER図なら、IDEF1X とかよりも概念モデル図に近くて伝わりやすいです。
- :pencil:複数のものを一つの箱に入れ、関係性に多重度が現れるというのが難しいお客様が多かった
- オブジェクト図はこういう時に使うのかという学びがあった
- こっちが慣れ親しんだものより、相手の土俵でやりたい
- とりあえず、同じ目線に合わせたい
- ベン図の重なり増やしたい
- DDDが目指している、ドメインモデルを中心にして同じものを見るようにする、というのはそれに通じるところよね。

---

# 深いモデル
## 目安の時間
- 15分

## 感想・気づき

- 「重要」と「複雑」「変化しやすい(ホットスポット)」とも違うので、プログラマとしての考えにとらわれないで、絶えず「”重要”なのは…？」と疑う姿勢でいかないとなと思った。(DEが満足していなかったエピソードから)
- 変化多点→「これがホットスポットや！」→重要…みたいに捉えてしまうと「プログラマの(ドメイン知識の)不理解でコードが多く変更された」が「重要」になってしまいそうに思えたので :+1:

## 疑問
- P.20〜21の例に出ているコンテナ輸送システムも、最初から複雑では無かったのではないか？　事業成長とともに、下請け会社を利用したりして複数の会社で責任の移動が発生するようになり、ドメインが複雑になってきたのではないか？　そして、それはこれからも複雑になり続けることを示唆しているような気がしているけどどうなんだろう。
- 「知識の噛み砕きは探求で、最終的にどこに行き着くかはわからない」と締めくくっているのもそうだし、P.15の「モデルは決して完成することがない。代わりに、進化していくのだ」というモデル・設計に終わりがないという話にもうなずける
- ドメインモデルを改良したほうが良い状況だと理解していても、余計な工数がかかるし、新規機能の開発が遅れてしまうのであれば、今のまま進めようという流れになってしまいます。ソフトウェアを再構築するようなモデルの見直しを進めるには、どうしたらよいでしょうか？ :+1: :+1: :+1::+1::+1::+1: :+1: :+1: :+1:
- :pencil:変更が求められているのかどうか、がまずスタートになりそう
- :pencil:レガシーソフトは触らない
- :pencil:レガシーソフトウェア改善ガイドの話かな
- :pencil:常にリファクタリングする
- リファクタリングを溜めれば溜めるほどリファクタリングの工数は増えてしまう
- :pencil:リファクタリング、リアーキティング、リライトの手段があるんですよね。
- まずリファクタリングでうまくいかなくなってから、それ以外を考えないとね。
- 基本的にはリライト以外でなんとかしたいところ……
- いきなりビッグリライトしたがる人が多い
- https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
- :pencil:「深いモデル」とは、ドメインの本質的課題を解決するモデルのことではないんですかね？リファクタリングしていったり、ドメイン分析を継続的にして行った結果として発見されるモデルでは。
- リファクタリングにより負債返済する話と深いモデルはちと違う気が。
- 負債返済しきっても、そこに蒸留されたモデルは無い気がする

## 深いモデルについての話
- リングフィットアドベンチャーのリングくんは深いモデルな気がする
- フィットネスを継続するためには、という問題をうまく解決ｓている
- 「フィットネスを飽きずに継続したい」というドメイン、関心事（問題領域）に対して、その表層と似ても似つかないが非常に上手く問題を解決する方法（ドメインモデル、解決領域）を導入したお話、てきな
- ので、ドメインモデルは現実世界の写像にはならないし、モデルに使われるユビキタス言語は、業務用語の一覧ではない
- 新しい概念は、深いモデルが生まれたことに依る結果であって、新しい概念のために深いモデルを作るのではないような印象
- 「イノベーションが目的じゃないなら、深いモデルは要らないよね」みたいな話にはならないよなーと
- https://www.infoq.com/jp/articles/domainframework_0930/
- 深い モデル（ deep model） 　 ドメインエキスパートの主要な関心事と、そこに最も深く関連した知識を 鋭く表現したもの。 深いモデルは、 ドメインの表層的な側面と素朴な解釈から脱却するものである。
- 用語集にある
- 「加重和」って言葉は割り勘の表層には出てきませんよね
- だから名詞抽出法でももちろん出てこない
- 名詞抽出はあくまでスタートラインくらいでそこからいかに深めていくかが重要なのでは。
- なので、対象に関する会話ややり取りで出てくる言葉だけでは完結しなくて、「そもそもXとは？」「AとBは常に両立する、とは何を意味するのか？」的な

- そもそも深いモデルを見ると、ドメインエキスパートは理解できないのでは
- そうですね。概念モデルから一歩踏み込んで分析モデルを作ると、そういうモデルも出てくると思いますね。ただ、どうだろ。ドメインエキスパートとの会話は表層のモデルとかでも会話できればいいのでは
- 妖怪や神話って、ドメイン設計の結果だと思ってます
- 名前をつけることによって、探求をし始める

---