DDD本 2章：コミュニケーションと言語の使い方
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

- https://discord.com/channels/432531367427964929/740202765619429487/751758889610903563

# 自己紹介

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

# 参加の仕方

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

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

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

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 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です。

---

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

## 感想・気づき
- 序章を読んでいて、うちの現場は人によって単語の使い方がバラバラなのに気づいた。チーム内で言葉をそろえるってすごく難しそう。:+1:
- 自分の経験としては、言語が揺れるチームは、そもそもモデルに対する意識を持っていないことが多かったです（第１部にある「モデルは、チームメンバ全員が使用する言語の基盤である」からも）。まずはそこの認識合わせが必要なのかと思ってます。:+1::+1::+1:
- エンドユーザーたち（ドメインエキスパートたち）の暗黙知を、きちんと言葉に定義する必要があると感じた。
- 「モデルとは、プロジェクトに携わる人々の頭の中で構築された概念の集まりであり、ドメインについての洞察を反映した、用語と概念間の関係性からできている」
- モデル is 何？となったら、この記述に立ち返るのが良さそう:+1::+1::+1::+1::+1:
- 「こうした図や会話は、アジャイルプロセスで再び強調されるようになったものだ」
- 「DDDは重厚・重たい」という評価をよく聞く（気がする）けれど、むしろDDDはアジャイル的なアプローチを強めに前提している感じ
- ここ以外でも、ちょいちょいアジャイルを念頭に置いた記述がでてくる
- よく言われる「DDDは重厚・重たい」という評価の発祥はどこか、「重厚・重たい」という評価はDDDの何に対して専ら語られているのか、気になる（本文に対する疑問ではないので、感想欄に記述）:+1::+1::+1:
- :pencil:IDDD本の例の表が起点になって、そこから諸々独り歩き、というのはありそう
- :pencil:でも、そのルートだけでもなさそうな気がする
- :pencil:IDDD本が起点だとしても、「重厚・重たい」という評価はDDDの何に対してか、という問はまだ残る:+1:
- :pencil:純粋にOOPがわからないレベルの人から考えたら難しい・時間がかかるってことなのかと思った
- :pencil: 設計をしたことがない人にとっては重いってイメージですね
- :pencil: 抽象的だから重い
- :pencil: リファクタを日常してない人には重い
- 小説か何かの作家の言葉で「登場人物が物語を形作る」という言葉を思い出しました

## 疑問
- 実は、エンドユーザーの間でも、言葉が統一されていないことがあるのではないだろうか？:+1:
- :pencil:ありました:+1:
- :pencil:部門が違うと違うよね
- :pencil:注文という言葉は解釈が違うことがよくある
- :pencil:システムが違うなら良いですけど、同じシステムなら統一したいですね
- 「用語と概念間の関係性」ってどういうことなんだろう:+1::+1::+1::+1:
- 言語化となるかんじ
- 単純に「用語と関連」ぐらいで良いんじゃないか、感
- モデルとは用語、関係性、この2つからできている（構成されている
- 「モデルとは概念の集合であり、（複数の）用語と関連によって構成されている」的な
- 「モデルとは、プロジェクトに携わる人々の頭の中で構築された概念の集まりであり、ドメインについての洞察を反映した、用語と概念間の関係性からできている」
- 原文
- > The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight.
- 訳ちょっとあやしい気がする、気のせい？ :thinking_face:
- 「概念間の関係性」の「概念間の」ってどこから引っ張ってきた？
- "a set of concepts"？でも relationships に the とかついてないし、結びつける根拠がよくわからない……
- 「ドメインについての洞察を反映した用語と関係性」でいいような
- DeepL先生曰く・・・
- > モデルはプロジェクトの人々の頭の中で構築された概念のセットであり、ドメインの洞察力を反映した用語と関係性を持っています。

:pencil:15分ほど討論した結果、とりあえず次の話へ進んだ

---

# ユビキタス言語
## 目安の時間
- 20分

## 感想・気づき

- P.24「言語の間にはこうした断絶があるので、ドメインエキスパートは自分たちが欲しいものをあいまいにしか記述しない。」
- ドメインエキスパートは要求を投げていて開発者側がドメインの言語を理解できるよう努めていない、と考えていたので、ドメインエキスパート側がそもそも情報を出し切っていないという観点が発見だった:+1::+1:
- 開発者側の視点からのユビキタス言語の必要性は感じていたが、ドメインエキスパート側の視点からもユビキタス言語の必要性があることに気づいた:+1::+1:
- 「ユビキタス」の対象に「開発者」と「コード」は入っていたが、「ドメインエキスパート」が入っていなかったことに気づいた:+1:
- P.24「共通言語のないプロジェクトの場合、開発者は、ドメインエキスパートのために通訳しなければならない。 ... 開発者同士でも通訳することがある。通訳することでモデルの概念を混乱させてしまい、それがコードの破壊的なリファクタリングにつながる。」
- 日本語話者にとってはこれらに加え、日本語と英語間の翻訳が必要になるため、大きなハンデを背負っているということを再確認した。:+1:
- 仕様書を書いてドメインエキスパートに見せたとき、ソフトのことよくわからないのでわかるように書いてっていわれることがあるが、これも共通言語じゃなくソフトの実装（DBとかAPIとかよりで書いていたから）だと思う。
- P.25 「これらの方言はどれも共通語になれない。どの方言もすべての要求には応えられないからだ。」
- ドメインエキスパートと開発者が共同で「より強固な共通言語」を作り出す必要がある
- ユビキタス言語をドメインエキスパート同士が違いに意思疎通をする際にも用いるというのはその通りと思う。同義語を少なくして一意な言葉にする必要がある。
- p.25 「ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている」
- 意識共有し、明示しておく言葉の範囲が広い。(実装する名詞、動詞、それを説明するのに必要な言葉)
- P.26「ユビキタス言語における変更は、モデルに対する変更であると認識すること」:+1::+1:
- 新しい知識を言語化することでモデルが変わり・実装が変わる
- 改めて言語化の重要さを噛み締めた感じ
- ここを読んでも「自分たちは特殊」と思っている人たちを一掃すべきと思った:+1::+1::+1::+1:
- こういった人は言語化の拒否なんだなと思った
- P.28が会話になっていないことだけはわかる。開発者がどんな実装をするか不安になる(想像すらできない)
- >「しなやかで知識豊富な設計を行うには、用途の幅広い、共有されたチームの言語と、その言語を使った活発な実験が必要である:+1::+1:
- チームの言語 == ユビキタス言語 == 共通言語 という理解をした
- 言語の定義は大事と理解できるし、まぁ聞く。 **"その定義した言語を使った活発な実験"** はあまり聞かないけど、言われれば「当たり前じゃ」って感じ。しかしここで明文化してくれてることに深く感謝:pencil:
- 活発な実験 == 「繰り返し行われブラッシュアップをしていく実践」という理解
- > 共通言語のないプロジェクトの場合、開発者は、ドメインエキスパートのために、通訳しなければならない。（中略）それが破壊的なリファクタリングつながる :+1:
- わかりみが深い（自分が（破壊的な）リファクタリングを強く言うときは多分「モデルの概念を混乱しているからそれのコードベースで整理をさせろ」（そして**誤訳かもしれないコード**を生む）ということなのかなぁと反省）:+1:
- > ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり
- となると、ドメインエキスパートも自分自身が **ドメインエキスパート** で、それの **役割** をわかってる必要がありそう
- 貨物輸送プログラムを完成させるのシナリオ２の会話中
- > 毎回作り直させるほうが簡単ですから
- > 常に、輸送日程がその仕様を引き続き満たしているか調べます。
- > 毎回比較する方がシンプルですよ
- シンプルにするうえで、上記のようなロジックにすることはある。この下りでユーザの言った通りにまんまロジックに落とし込むと複雑なんだろうなぁとしみじみ。（ただ、それがDDDでは正しいのでは？とも思ったりもする。シンプルにしたロジックをユーザに認識させるのは重要だろうけど、理解してくれるか？とも思ったり）:+1:
- p.24 冒頭のルイス・キャロルの詩
- [全文](http://www.online-literature.com/carroll/2822/)
- 元々は、「詩人は生まれつきの才によるものなり」という格言に対するパロディらしい
https://core.ac.uk/download/pdf/228567011.pdf
- p.27「ユビキタス言語は生き生きとした形式で伝える」
- ユビキタス言語にせよドメインモデルにせよ、使う人が作る側面がある点であったり、「生き生きとした」という表現だったり、やっぱりアレグザンダーの影響がここにもでているのかしら、などと思ったり（にわか知識）
- 参考文献の最初の2冊がアレグザンダーなあたり、意識していそうな気はする
- p.26-27にかけて、ユビキタス言語はどんどんと変更されるものであり、またその変更はモデルへの変更をも意味する、ということが語られている:+1:
- このことから、ユビキタス言語 ≠ 業務用語、ビジネス用語であることは明確に言えると思う:+1::+1::+1:
- p.26「こうした専門用語も、あいまいで矛盾があるのだから、そのまま使用することはできない」
- ユビキタス言語は、単に顧客・ユーザーの言葉を一覧にしたものではなく、開発者の用語をまとめたものでもなく、ドメインモデルを記述するための基本語彙・文法
- また、ユビキタス言語は開発者とドメインエキスパートの相互の協力によって構築されるもの。予め用意されたものでも、自明に所与としてあるものでもない。
- p.27「ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり〜」
- p.28〜29 の比較で抽出された知識
- 「荷受け地」「荷出し地」「通関地点」のセット = 「経路仕様」
- 経路計画を作り直す = 古い輸送日程を削除して、新しい経路仕様に基づいた新しい輸送日程を生成する
- 経路仕様と輸送日程の関係が明確にされた
- 経路仕様が変更されたら、輸送日程はどうなるか？
- 会話の最後で「輸送日程は経路仕様が満たされなくなったときにしか生成されない」という知識が出現している
- 要件定義や開発見積もりを始める前に、開発者とドメインエキスパートの間で、ユビキタス言語を統一しておくのが理想だと思った。:+1:
- :pencil:でも、これにより「最初だけ」ってバイアスかけたくなくて「途中でもどんどん決めてく・変えてく」には合意しときたい
- 自身の経験だが、開発を進める過程で、徐々にユビキタス言語が生まれていく事もあった。:+1::+1::+1:
- ときにはUML以外の図を利用するほうが、理解しやすいというのは、自分にとっては少し衝撃的だった。 :+1::+1: :+1::+1:
- そもそもUMLを理解するのには前提知識が必要。コミュニケーション手段としては、学習コストが高いものなのかもしれない。
- 「言語に亀裂があると、プロジェクトは深刻な問題に直面する。」
- 同じ概念について話しているはずでも、使う言葉が違うことで誤解が生まれたりするので、これはほんとに大事だと思う:+1:
- 加えてこれはドメインエキスパート間、開発者間、ドメインエキスパート対開発者間などのあらゆる関係性に置いても起こりうる危険性があるのも改めての気づきだった
- 開発者としては実装するだけではなく、チームと共同で一つの言語を作り上げるというスタンスが大事 :+1:
- 「言語に対するこうした変更は、ドメインモデルに対する変更として認識され、用語の意味が変わった場合には、チームがクラス図を更新して、コード中のクラスやメソッドの名前を変えたり、ふるまいを変更したりすることにまでつながる。」 :+1:
- Railsでは、ActiveRecordパターンを利用しているため、クラスを変更しようとするとAlter Tableしないといけない。上記まできちんと実践しようとするとアーキテクチャレベルで制限が生まれそう
- 通訳と伝言ゲームをしまくった結果、「それが当たり前」になった…の成れの果てが「詳細設計書」と「コーダ(蔑称としての、そのままコード化する人)」なのかなって思った
- それやってるチームは「仕組み的、構造的にユビキタス言語にはたどり着かない」のかなとも
- 多くの章で「組織構造の変更」が必要…ってなるなと:+1:

## 疑問
- p.24「ドメインエキスパートは自分たちが欲しいものをあいまいにしか記述しない」
- そもそも自分たちが頭の中で描いていることを厳密に記述できる人間はほとんどいない（あるいは、そんなことはできない）ので、ちょっとフェアではない書き方に感じる
- 記述しないではなく記述できないというニュアンス？
- P.25「モデルの中にある概念間の関係性は、あらゆる言語に存在する結合規則となる。また、単語やフレーズの意味には、モデルのセマンティクスが反映されている」の説明がよくわかっていない
- モデルのセマンティクスとは:+1::+1::+1::+1::+1::+1::+1::+1:
- 単に単語の意味があるだけでなく、モデルに適したニュアンスがしっかり含まれている単語になっているという話だと思いました。似た意味の単語が複数存在する中で、その言葉が選ばれているのは洞察を繰り返したから。だからこそ、その単語にはモデルのセマンティクス（意味）が反映されているのかと自分は解釈しました。
- :pencil: 前回予告したSemantic Webの話をする前に，IT用語の中でもイメージがわきにくい言葉のひとつである「セマンティクス」について解説しよう。セマンティクスとは「データの意味」のことであり，シンタックス（データの形式や構造）に対応する概念だ。ずいぶんアカデミックな議論をしているかと思われるかもしれないがそうではない。これは，企業のアプリケーション統合を考える上でも，きわめて重要なポイントなのだ。
- :pencil: モデルの意味/文脈が反映されている
- :pencil: モデルが伝えたい本質（解釈）、くらいで適当に理解してました:+1:
- :pencil: モデルで表現された/形式化されたものが表す意味、あるいはモデルで表現した対象の意味、くらいかと
- この章に限ったことではないが「ユビキタス言語」「ドメインエキスパート」「スコープ」といったキーワードって、日本語に置き換えられないだろうか？:+1::+1: :+1: :+1::+1:
- 思いつき
- ユビキタス言語
- 共通言語
- :pencil: 「ubiquitous = in every where」で、ただ言葉を合わせましょう、以上に「会話でも、コードでも、ドキュメントでも」っていう意味が込められてるので、「共通言語」以上の意味を持つのだと思います:+1:
- ドメインエキスパート
- 業務管理者、とか？あまりしっくりこない。
- スコープ
- 文脈
- :pencil: 「日本語に置き換えられないだろうか」という発想の動機というか、モチベーションを聞いてみたい（あんまり考えたことなかったので）:+1:
- カタカナ語って、意味が分かりづらいと思うんですよ。日本語だと、漢字の部首なんかで、なんとなーく意味を推測できてよいかな、と思うんです
- :pencil: 「ubiquitous = in every where」で、ただ言葉を合わせましょう、以上に「会話でも、コードでも、ドキュメントでも」っていう意味が込められてるので、「共通言語」以上の意味を持つのだと思います
- :pencil: 日本語にすることで失われる意味はあるので、あえて日本語にしていないと思います
- :pencil: 「言語」なので、語彙の他に文法（結合規則）も含んでいる
- OOUIなどで用いられる言語と一致させる必要はあるのだろうか？UIを通してユーザに認知されるモデルと開発者がチーム内で用いるモデルは別の方が良いのか？同じ方が良いのか？ :+1::+1::+1::+1::+1::+1:
- :pencil: UIはまた別のコンテクストなので、別のユビキタス言語が構築されると思います
- :pencil: バックエンドとフロントで同じ物をさす言い方が違ったら困るかなとは思います
- :pencil: 一致しとかないときつくない？ UI チームに伝えた内容がサーバーに伝わらねぇんだけど！？　みたいな
- :pencil: むしろ、UIの関心事とビジネス上の関心事が全く一致する、というのに疑念を感じてます
- :pencil: 多分、言葉の一致の話と、サーバーサイドのクラスとフロントの受け取ったクラスを一致させるかって話は少し混じっているかなと思って
- :pencil: 具体例
- :pencil: ECのカート画面とかだと、UI的には価格・個数・商品名・商品画像を知りたいけど、販売期間とか在庫数とか原価とかまでUIに知らせますか（知らせたいですか）的な
- :pencil: ECサイトだと、購入前は「カート」って表現してたけど、購入後は「履歴」って表現してた’
- :pencil: UIの都合でおうおうにしてあるけど、根底にあるモデルは一緒になるべきでは
- :pencil: バック側は専ら整合性が中心で、UIはユーザーが「したい」と思ったことを「した」と思ったとおりにできるようにする、が中心的な命題だと思ってます / モデルが一致するなら、保持する知識も全く一致することになりますが、UIでは整合性よりも画面上で表示とインタラクティブが重要で、本当に一致する？的な
- コンテキストどうわける？　の疑問へ
- まったく違うものを同じ名前で呼んでた→コンテキストを分ける
- まったく同じものを違う名前で呼んでた→同じ名前にする
- まったく同じものを同じ名前で呼んでた→素晴らしい
- まったく違うものを違う名前で呼んでた→素晴らしい
- 「ドメインエキスパート（ユーザ）」と「開発者」という書き方をされているが、「（先任の）開発者がドメインエキスパートである」というようなこともありますよね？:+1:

---

# 声に出してモデリングする
## 目安の時間
- 15分

## 感想・気づき
- P.32「表現すべきことをより簡単に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること」
- 「簡単に言う方法を見つける」という発想はなかった:+1::+1:
- :pencil: 簡単: ユビキタス言語 / 複雑: 「会話でも、コードでも、ドキュメントでも」使う共通言語
- :pencil: 良く「それって、”XXX"(短い言葉)って呼んでもええやつですかね？」は、現場でよく言ってる気がする。 (とくに、旧実装とか「慣例的に呼んでるが、絶対違うやろって用語』については)
- 「図とコードに再び反映」は継続的なリファクタを意味していると理解
- 第2章全体にわたるが、「言葉」ではなく、「言語」という単語を使っていることがひっかかった。「ユビキタス言語を作る」というのは、プロジェクトの用語集を作るようなイメージでいたが、スペイン語講座の例から考えると、プロジェクト用に全く新しい言語を作り、DEや開発者の区別なく浸透させていくことなのだと気づいた。
- P30「機能を説明するにあたって、ビジネスの専門用語や、門外漢によるその意訳が使われているのがわかる」の部分が、下手なたとえ話を用いるとかえって場が混乱した経験を思い出した。
- とはいえ適切なたとえ話は難しい…:+1::+1:
- :pencil: 伝え方が上手い人は相手の立場に立てる人だなぁとつくづく思います。そんな人は自分より相手の土俵で例えそう。
- コードコンプリートの序盤にある「ソフトウェアメタファ」について思い出した...
- エヴァンスさんが言っていた「言語を生み出す本能」が気になって買ってしまった。まだ上巻だけだけど。 :clap: :+1::+1:
- p.32「シナリオを声に出して描写すること」「新しい考え方を図とコードに再び反映させること」
- まさに「持って生まれた才能を十分に活用」している風景:+1:
- 視覚・空間・聴覚・論理、あらゆる能力をフル活用する、というのがこの節で伝えたいことなのかなあ、という感想:+1:
- 音声によるコミュニケーションは、ワーキングメモリに負荷がかかるのかもしれない。
- 声に出すことで、そのモデルが、ワーキングメモリにやさしいかどうかチェックできるのだと思う。
- 抽象的な概念を図や言葉で「名前づけ」し、言語を介して共有できるようにすることがモデリングということと理解した:+1:

## 疑問

- P31「コードの持つあの不思議な感じを使うのと全く同じなのだ」という文章の「感じ」がわからない :+1: :+1: :+1:
- :pencil: コードを読むときに、一次元のテキストとしてだけでなく、そのテキストが示唆するメソッド同士の依存関係とかクラス同士の繋がりを、脳内で2次元の図（UML的な）で想像したり、3次元空間で箱同士がつながったり離れたりする映像としてイメージする、みたいな感覚で捉えてました（自分はよく←みたいになります。一例として）:+1::+1:
- :pencil: 「テキストだけが頭を駆け巡るわけじゃないよね」的な意味と解釈してます
- ここでの **モデル** とは以下のような認識で合ってますか？
- モデル1 == 経路選択サービス
- モデル2 == 経路仕様
- モデル3 == 輸送日程
- モデリング作業Last == 「**経路サービス**は、**経路仕様**を満たしている**輸送日程**」と声に出すこと

---

# 1つのチームに1つの言語
## 目安の時間
- 15分

## 感想・気づき
- P32「豊富な知識を持つドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題があるのだ」という言葉は、開発だけで進めて最後にドメインエキスパートにレビューしてもらうときに首をかしげながら納得してもらってたから刺さる。 :+1: :+1: :+1::+1:

- > 豊富な知識を持つドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題があるのだ
- バーンと効果音が付きそうなお言葉。耳が痛い。ただこれってモデルのレビューが必須そう。ドメインエキスパートがモデルの重要性を理解しモデルをレビューをし、モデルをリファクタし、またレビューしてもらうというサイクル必須だよなぁ（そういう時間をいかに言葉巧みにとらせるか） :+1: :+1: :+1: :+1::+1: :+1: :+1:
- :pencil: レビューより、一緒に作るのが理想という話ではありますよね
- :pencil: 可能であれば）レビューするというよりは一緒に作りたいですね
- :pencil: 会話しながら作っていって、いまいち伝わっていないとするとモデルがおかしいとか、そういう意味で捉えてました
- :pencil: これ自分が書きました。読んだとき、一緒に作るって時間を結構いただくので、持ち帰って練ってこういうことで合ってる？っていう認識のすり合わせ==レビューと書きました
- :pencil: 叩き台をエンジニアが作る、とかは実務上は全然ありますよね。
- 「ドメインエキスパート」「ユーザ」が別で表現されてることに対して違和感を感じてたけど、慣れてきた
- （「ドメインエキスパート」==「ユーザ」だと認識してた）:+1::+1:
- きっと「たまたま同じ時もあれば、違うときも結構ある」 :+1: :+1:
- :pencil: toCはほぼないかと。toBはイコールもあるけども。
- :pencil: p.519 ドメインエキスパート：ソフトウェアプロジェクトのメンバーで、ソフトウェア開発ではなく、アプリケーションのドメインの担当者。ソフトウェアの単なるユーザと違い、ドメインエキスパートはその対象に関する深い知識を持っている
- > 新しい言語が進化するにつれて、ドメインエキスパートは、その言語を身につけて、依然として重要な古いドキュメントを改めて修正するといった余分な努力もしなければならない。
- DDDを知らない実質ドメインエキスパートな役割を持つ人にこういうこと（余分な努力）を要求しますよと伝える必要がありそう
- ドメインエキスパートって何？ってなってきそう
- > P.32「ドメインエキスパートが、開発者との議論や、自分たちの中での議論にユビキタス言語を使用すると、モデルが自分たちの要求を満たすのに不十分であったり、誤っていると思われたりする領域を素早く発見する。」
- ドメインエキスパートに対して気をきかせて翻訳したつもりでも、『多分そんな感じ』という反応が返ってくる、という経験から強く納得した。やはりユビキタス言語は大事。:+1:
- p.33「モデルを非公式にテストすることができる」
- ドメインモデルを使った会話 = モデルに対するテスト
- TDD！ TDD？ :thinking_face:
- こう、テストでエラーを検知しながら（モデルの）設計を更新していく、的なアレにTDD風味的なサムシングを感じた :+1:
- 「モデルオブジェクトを段階的に使用」するのもミソな気がする
- いきなり全部用意してから会話ではなく、曖昧さやぎこちなさを発見しながら、モデルオブジェクトを **段階的に** 発展させていく
- p.33「アジャイルプロセスでは、要求がプロジェクトの進行に合わせて進化する。（中略）この進化の一部として、改良されたユビキタス言語を用いて要求を再構築しなければならない」
- やっぱり、DDDはアジャイル（的なアプローチ）を強く前提にしている:+1:
- そして、DDDは「事前に全てを記述しきる」「完璧なドメインモデルを組み上げてから開発する」という方法論でもない、ということも明確。:+1:
- モデルの記述に使うべきユビキタス言語自体が、段階的に進化するものとして定義しているので
- P.32 「ドメインエキスパートは、モデルの言語を使ってユースケースをかけるし、また受入テストを定義することで、より直接的にモデルに取り組める」
- ユースケースをかけるエキスパートがユーザ側にいると話は進めやすいと感じた。大体、開発者が話を聞いて書くことが私の周りでは多いから。
- スクラムのスプリントレビューを真面目にやっていくと、チームの言語が洗練されるそう:+1:

## 疑問
- p.32「新しい言語が進化するにつれて、ドメインエキスパートは、その言語を身につけて、依然として重要な古いドキュメントを改めて修正するといった余分な努力もしなければならない。」
- 「余分な」という表現が引っかかる。
- ここまでの流れで、「言語を身につけて」「ドキュメントを修正する」ことを「余分」と言うんだろうか？
- 原文だと *As the new language evolves, the domain experts must make the extra effort to adopt it, and to retrofit any old documents that are still important.*
- *extra effort* の訳として「余分な努力」があてられてるっぽい
- 文構造的に、 *extra effort* は「ドキュメントを修正する」ことだけでなく、明らかに「言語を身につけ」ることにもかかってる
- ますます引っかかる……
- ここまでの流れで、「言語を身につけ」ることを「余分」と言うか？
- *extra* の意味は *more than is usual, expected, or than exists already* 、 類語は *additional*
- https://www.oxfordlearnersdictionaries.com/definition/english/extra_1?q=extra
- 「余分な」というより、「より多くの」「普段以上の」「より一層の」ぐらいに読んだほうが良さそう？

---

# ドキュメントと図
## 目安の時間
- 15分

## 感想・気づき

- p.36「図が表現しているのは、考え方の骨格なのだ」
- 何を「図」に求め、何を「図」に求めないか、の指針になりそう:+1:
- P.36「設計に関する本質的な詳細は、コードにおいてとらえられる。」:+1:
- P.36「ひとたび永続的な形式になってしまうと、ドキュメントはプロジェクトの進捗とのつながりを失ってしまうことが多い」
- これはとてもわかりみが深い。:+1::+1::+1::+1::+1:
- Wikiに書くことは、石に刻むような感じで、あとからなかなか修正されづらい感じがある。。。:+1:
- コードも設計書もちゃんと修正してこそプロだ、みたいな言われ方もするが、そこに行き着く前に情報量を減らさずにメンテするものを減らすとか、そういう努力をしたい。:+1:
- ちなみに、具体的なドキュメントについては、第4部で示されているらしい。
- :pencil: つながりを失うというか足枷になるんですよね

- > 図を作成するにも、それを読むにも、とにかく手間がかかりすぎるのだ。
- 図マンセー派だったけど、心当たりはあるので考えを改めないとなと思った（よくでる「バランスが大事」というキーワード。これがまた難しい...。線引きとなる基準が欲しい..「図にする/しない」ところまで考えてたら前進が遅く感じるのは慣れてないからなのかなぁとおもったりもした）
- > モデルは図ではない
- 忘れがちなので、常々意識したい
- ただ疑問が生まれた（モデルとは）:+1::+1::+1::+1:
- :pencil: モデルの定義はDDD Referenceの方がわかりやすくて https://domainlanguage.com/ddd/reference/
- > ドキュメントはコードや会話での表現を補わなければならない
- 設計の理解において、補助的な役割を担うだけであり。ドキュメントが全てではない。あくまでセットの中の1つであるという理解をした（例えば**コード**と**会話**と**ドキュメント**の3要素で設計の理解をする）
- > 既にコードがうまくやっていることを、ドキュメントでもやろうとするべきではない。
- 刺さる刺さる。 :knife: :knife:
- ドキュメントがない状態で5年もののプロダクトがあったとする。新しい機能の実装に関してはドキュメントを添えるかもしれない。その新しい機能が古いロジックに依存していた場合は、古いロジック部分はドキュメント化するしないで迷いそう
- P.37「詳細については、既にコードが提供している」。ドキュメントが提供する必要があるのはもっと俯瞰的に見れるレベルの話なんだと思った。
- 「書かれたドキュメントは、コードと会話を補足すべきである」この意識を常に持っておくのは重要だと思った。:+1:
- 古いおじさんに、コードで表現できているのに設計書・仕様書がないっていわれるのがつらい。ごまかす方法検討中。:+1:
- > P.37「モデルをドキュメントに書き出す場合、私は、そのモデルの厳選した小さなサブセットを図に書き、その周りにテキストを書く。クラスとその責務を言葉で定義し、意味を支えるコンテキストの中に囲い込む」
- いわゆる **外設** で、処理の概要を細かくなりすぎないように調整しながら書いていたけど、『図とその周りにテキストを書く』という手法で応用/代替できそうな気がしてきた。
- P.38「手書きの図は、労力を節約できるし、形式張らないその場限りのものであるという印象を与えるという利点を持っている」
- これはよくわかる。
- キレイに整頓された図は、他の人が変更を加えることに躊躇をするし、作った本人でさえも棄てることに幾らかの労力を使う
- 現場で役立つシステム設計の原則の9章でも、ホワイトボードに書いた手書き図を写真に収めて共有するのが一番手軽な方法だと言ってたので通じるところはありそう。:+1:
- P.38「それに、ドキュメントが重要な役割を果たしていないなら、純然たる意思と規律をもってドキュメントを最新の状態に保つことは、無駄な努力である」
- ドキュメントが果たすべき重要な役割とは、同Pの「モデルの概念を説明すること、コードの詳細を書き進める上で役に立つことや、モデルで想定されている使用方法についての洞察を与えること」だと読み取った。 :+1:
- モデルと図の違いについて、個人的イメージ
- モデル = 対象となるドメインを実現するために取捨選択・抽象化された概念構造、知識体系
- 図 = モデルの概観を空間的に表現したもの
- コード = モデルの詳細を表現したもの
- ユビキタス言語 = モデルの構造・体系を記述されるために使われる言語体系（＝語彙・文法）
- **モデルそれ自体**と**モデルの表現・描写**は区別しよう、的なイメージ > 「モデルは図ではない」 :+1: :+1:
- 「りんご」と、「りんごを描いた絵」「りんご型の置物」「りんごの色・形・味を記述したテキスト」はそれぞれ違うものだよね、的な
- :pencil: 個人的な説明の仕方ですけど、「モデルとは現実世界の射影ではなく、その概念をどのように捉え、どのように扱いたいかを表現したものである」って説明しています
- :pencil: [DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか](https://www.slideshare.net/koichiromatsuoka/ooc-2020-matsuoka/25)
- :pencil: 個人的には経済学の数式モデルとかと同じかと思います。 あれも実際の現象の一側面しか表せないので
- :pencil: 「モデル」って、全世界で意味が統一されているわけではなく、文脈によって全然違うものなので、 DDD輪読会としてはDDD文脈の定義を正とするのが良いと思っていまして その定義がevans本末尾の用語集か、DDD Referenceの定義を正とするのが公式採用という意味でいいかなーと思ったりします
- 図を描く前提条件として、ユビキタス言語が必要だと感じた。:+1:
- 文字が存在しない図は描けないので... その図が何を表しているのか説明するためにも、ユビキタス言語が必要だと思う。
- 「ドキュメントを最小限に留め、その焦点をコードと会話の補足に絞ることで、ドキュメントがプロジェクトに結びつけられた状態を保つことができる。」
- 詳細を語ろうとするのではなく、モデル上コアな箇所に絞ることで最新の状態を維持できるようにするという意味と理解
- この章全体を通して、エヴァンスも _UML だけですべてを表すのはムリ(要約)_　と言っていて、今までの経験と勘は間違ってなかったんだな、とちょっと安心した。

## 疑問

- P.36「適切に書かれたJavaには、UMLと同じくらい豊かな独自の表現力があるのだ。図を注意深く選びぬいて構築すれば、意識を集中して話をすすめるのに役立つ。ただし、モデルや設計を完全に表現しなければいけないという脅迫観念のせいで、わかりにくくならなければ、の話だ」
- 適切なモデルを作っても、それを忠実にコードで表現しようとしたときにわかりにくくなってしまう話に聞こえるが、どういうパターンがこれに該当するのだろう。
- モデルとは何か
- 次章？
- 次の「説明のためのモデル」を読んで思ったの「**表現** と言い換えてもいいかもしれない」
- ドキュメントを最新の状態に保つ必要がある...ということは、ドキュメントの共有方法とバージョン管理方法は、かなり早い段階で準備しないと行けないのでは？
- 組織や環境を変えていくようなパワーやメンタルが必要になりそう...

---

# 説明のためのモデル
## 目安の時間
- 15分

## 感想・気づき

- > 両方の図を一緒に見た方が、それぞれを単独に見るよりも理解しやすくなるのである
- たしかに！:+1::+1::+1:
- コードに落とし込むときは図2.4をメインでサブに図2.5
- 新しく入ってきた人に説明する時は、図2.5をメインにサブで図2.4
- 図2.4 のようなクラス図があっても全然頭に入ってこないし説明しにくいしで困っていたけど、図2.5 のような形式で表して、両方の両方の図を作っておくのは効果がとても高そうに感じる。図2.5の形式にするかどうかは分からないけど、エッセンスは真似たいと思う。
- 図2.5 は、このままでも良いけれど、頑張ればもっとわかりやすくなりそう。
- 一方で、図のメンテナンス性を考えると、このままのほうが良いとも感じる。
- この章で言いたかったことは、オブジェクトモデルとしての図を作成するだけでなく、それを補足説明するた別の角度でモデリングして図を作ることも有効だよ、と言うことかなあ

## 疑問

- 説明のためのモデルは、冒頭で言っている「実装、設計、コミュニケーションの根底にあるモデルは1つであるべき」というものとは、別種のものとして扱うという解釈で良いのか。
- その場限りの説明に使うような図みたいな。
- 違いがちょっとわかっていない。
- :pencil: 冒頭のモデルは「設計を推進するモデル」に分類されそう
- ここで描かれている2つの図は、異なる「モデル」なんだろうか
- 一つのモデルに対する、異なる表現のようにも見えた
- だとすると「モデルは図ではない」を自分で踏んでいるようにも見える:+1:
- 一つのモデルに複数の図（＝表現方法）が有っても良いはず:+1:
- 2.4が表しているモデルと 2.5が表しているモデルは、注目している知識・概念が違う、ということ？
- 注目している知識・概念が違うので、表面に出ている言葉（＝知識の取捨選択結果）も違う
- 注目している知識・概念が違うので、選択される表現方法（＝図）も違う
- 前者は知識同士の関連や全体構造に注目したモデルで、後者は実際のシナリオ・フローに注目したモデル？
- :pencil: 視点が違うで良いと思います。UMLも同じものも別の図で表現しますしね
- :pencil: モデル＝抽象化物という定義なんで、抽象化の切り口が違うことは全然あり得ますよね
- :pencil: モデルを２つの表現で表していると思ってました。
- :pencil: 「視点(視座)」のハナシは、「モデル相手してる限り、ずっとつきまとう」から、大事にしたい。
- :pencil: 同じ映画でも、監督で作品が変わる的な話のイメージです
- :pencil: なんとなくだけどモデル = オブジェクト図って固定観念からスタートしてしまっていると混乱してる気がする
- :pencil: クラス図も、目的を持った抽象化物なんでモデルの一種ですうよね
- :pencil: モデルと呼ばずに、両方とも図っと言って欲しい気がします。
- :pencil: モデルに、図も、文字列も、含まれると思います。現実世界を抽象化して表現するときにどういう手段を使うか、という話で、それは図かもしれないし文章かもしれない
- :pencil: （個人的には）こう言うところの説明がかなりおおざっぱなのでDDD本だけだと戦略設計ってちゃんとできないんですよね。全然銀の弾丸じゃないというか。
- :pencil: 触れられないものがあるのは非常に共感を持てます その上で、それはモデルではないと思ってますー それをなんとかして表現しようとしているからモデル（模型）だと思ってます

---