アート・オブ・アジャイルデベロップメント読書会 6.4 ユビキタス言語
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/03/14](https://discord.com/channels/767540649418686486/774111081634332673/785112149344780289)

# 自己紹介

- ファシリ役
-
- 読み上げ役
-

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

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

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

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

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:30- | - | もくもくタイム（hackmd書き込み） | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:45 | 70分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:45-21:50 | 5分 | [miro](https://miro.com/welcomeonboard/DgN2fhzWfBt3jHeC1h5Clteo4TvoXmS6Hx06eM46RiQEpjkVv52ZlMeu8u2nLRJ0)を使って振り返り | |
| 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | |

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

# 感想など

## 目安の時間

- 1トピックにつき10分を予定しています
- 盛り上がったら延長することもあります

## 感想・気づき

99単語のまとめ (https://www.jamesshore.com/v2/books/aoad1/ubiquitous_language)
- > Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the software think and speak about their work. One powerful approach is to create a domain model.
> The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results.
- > プログラマーは、ミスコミュニケーション、遅延、エラーを避けるために、ドメインエキスパートの言語を話さなければならない。ドメインの言語とコードの間の精神的な翻訳を避けるために、ドメインの言語を使用するようにソフトウェアを設計する。ソフトウェアのユーザーが自分の仕事についてどのように考え、どのように話すかをコードに反映させる。一つの強力なアプローチは、ドメインモデルを作成することである。
> ユビキタス言語は生きた言語である。ドメインの専門家が設計やコードに影響を与え、コーディング中に発見した問題がドメインの専門家に影響を与える。矛盾を発見したら、それは会話や共同発見の機会となります。そして、その結果を反映してデザインをアップデートする。

### 6.4.2 2つの言語

- > このシナリオの問題は、あなたとあなたの友人が2つの異なる言語を話していることです。あなたはあなたが道路で見ているものについて話していて、あなたの友人は彼が彼の地図で見ているものについて話している。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866284218861617162)
- わかりやすい例え。ユビキタス言語にかかわらず、相手にわかる話し方をしようという説明に使いやすいかもしれない。:+1::+1::+1::+1:
- これ、自然とそうなっちゃっているパターンが多いと思うけど、どうやったら早めに気付けるかなって思ったりする:+1:
- [これ](https://takatakijou.hatenablog.com/entry/2020/11/06/%E7%94%B7%E5%A5%B3%E5%B7%AE%E4%BC%9A%E8%A9%B1%E5%AD%A6_%E8%A7%A3%E8%AA%AC%E3%80%8C%E8%BB%8A%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3%E3%81%8C%E3%81%8B%E3%81%8B%E3%82%89%E3%81%AA%E3%81%84)を思い出した

### 6.4.3 同じ言語を話す方法
- > プログラマがドメイン専門家の言語を話すべきだ。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866297291371184179)
- まあ、当たり前ですが重要な出発点かと
- 今更だけどなんで逆はありえないんだろう。直感的にはプログラマがドメイン専門家の言語で話すべきなのは分かっているけど、うまい説明が思いつかなかった:+1::+1:
- 顧客の要望はドメイン用語ベースで行われるので、仮にチームがテクノロジ言語ベースで会話したとしても、ドメイン専門家に翻訳作業が発生し、記載のあったようなデメリットが発生してしまいそう。
- ソフトウェア開発以前からドメインはそこにあるから、そこを足場とした方が自然に活動を拡張していけるというのもある。
- ビジネスで考えると、困りごとをこうしたいという思いが先にあって=ドメインに対する考察が生まれて、そこから技術的にどうするかという流れが普通なので、自然とドメインの言語で話すことになる気がする
- > 心の中で「こいつらが何を言っているのか分からないや。でもそんなこと言ったら、もっとややこしい話をしてくるんだろうな。ごまかしておく方がよさそうだ」
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866286426538246156)
- 仕事が忙しいとか体調が良くないとか些細なきっかけでこういう思考になってしまうことがあるので、改めて気を付けようと思った:+1::+1::+1::+1:
- こういう時は顔に出ることもあるので、リモートだからこそビデオONで話すことも重要:+1:

### 6.4.4 コード内のユビキタス言語

- > より良いアプローチは、ドメインの言語を使用するようにコードを設計することです。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866281300184793088)
- ドメイン言語の日本語を、コードで英訳することでニュアンスが変わったりしているのはよく見かける話。この辺りを見ると、日本語プログラミングに舵を切る勇気も重要なのかと思う。あるいは、ユビキタス言語を和英用意する？:+1::+1::+1::+1::+1::+1:
- よくあるのは、モデルの隣に英訳も一緒に書いておくくらいかなぁ。
- ドメインの言語でコード、となってくると、結局のところDDDが必要という話になってくる？
- > ドメインの言語を使ってアプリケーションを設計するための強力な方法はドメインモデルを作ることだ。

- Wirfs-Brock & McKean の本って何かと思ったけどこれかな？
- https://www.amazon.co.jp/Object-Design-Responsibilities-Collaborations-Addison-Wesley/dp/0201379430 :+1:
- 日本語版は絶版ぽい https://www.amazon.co.jp/dp/4798109037?tag=shoeishacom-22 :sob::sob::sob::sob:
- > なぜならコードを書くには妥協を許さない正確な理解が必要になるためだ。認識のズレを浮き彫りにしよう。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866292084986085416)
- 「妥協を許さない正確な理解」がいい表現だと思った。:+1::+1::+1:
- このことを意識していれば、自然とドメインへの理解が必須だと思える気がする。

### 6.4.5 ユビキタス言語を磨く
- > ドメインの言語を自分の言語 に置き換えてはいけない。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866288997042880523)
- 暗黙的な概念（ドメインモデル等で表面化していないもの）を発見し、ドメインモデルに組み込んで設計が上手く行った例を聞いたことがある。
そういった開発者サイドからユビキタス言語を増やすシーンがあった場合、それがドメインエキスパートに認められている概念なのかは、コミュニケーションを円滑にするメリットからも、都度都度気をつける必要があると思った。
エンジニア側の自己満で終わっているなら、例えそれがテクノロジ言語でなくても、それを使っているのと全く同じ。:+1::+1::+1::+1:

### 6.4.8 使用上の注意

- > もしチームと同席しているドメイン専門家がいなければ、ユビキタス言語が持てるほどドメイン専門家の思考プロセスを深く理解するのは難しいかもしれない。しかしこういった状況では、ユビキタス言語を試してみるのがさらに重要になる。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866293979661074473)
- その考えはなかった。でも、可能なのか？:+1::+1::+1:

- > ドメイン中心の設計をするためには考え方を大きく変える必要があり、簡単なことではないかもしれない。
- DDD難しい問題

- ドメイン中心の設計をしたことがないチームもある。もしあなたのチームがそうなら、気をつけて進めよう
- 未経験なところだと出来るのだろうか？　って思ってしまう :+1::+1:

- 真の顧客の参加や全員同席が大事そう

### 6.4.9 代替案
- > ドメイン専門家の言語を話すのはいつもよい考えだ。しかし、ビジネスルールがわずかしかない技術中心の小さなプロジェクトの場合には、ドメイン中心の設計を避けた方がよりシンプルな設計になるだろう。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866295485476372500)
- DDD"やりたい"って話が出ると身構えてしまうのは、こういう点を考えての発言か読み取れないのもあると思った
- 最初のうちはビジネスルールは少ないと思っていたけど後から増えるパターンもあり得るだろうから、なんとも言えない気持ち:+1::+1::+1:

## 疑問・参加者に聞いてみたいこと

- > ドメイン中心の設計を「真」のオブジェクト指向設計と呼ぶことがある - p.132
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/866279866928332810)
- この呼称は、流石に甚だ疑問と言わざるを得ない:+1::+1::+1::+1:
- ドメイン中心以外のモデリング技法やアプローチを「オブジェクト指向」においては認めないかのような主張にしか見えない
- そもそも、ドメイン中心のモデリングと「オブジェクト指向」のアプローチは親和性が高いというだけじゃないかと思う。そこに必然性が有るかというと、疑問:+1:
- ドメインを中心とするモデリングアプローチには賛同するし、価値が有ると思うけど、それ以外を「偽」かのように扱う呼称はさすがにいかがなものか
- Xに賛同することと、Xこそ「真」と主張することは別の話:+1:
- そもそも誰が言ってるんだろう？（出典書いて……）
- 「オブジェクト指向」という発想・アプローチに基づくドメイン中心以上の何かを生み出す可能性を「それは偽である」という文句の下に事前に潰しかねない、という点も非常に気になる
- 「オブジェクト指向」という言葉と「ドメイン駆動」という言葉の両方を矮小化する表現じゃないのか:+1::+1:

----

## ミニエチュードの質問
* ミニエチュードは、このプラクティスに対して気づきを得るための質問です
* 詳細はP76ページを参照してください
* 以下の質問に、回答を継ぎ足していってください

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)