はじめに
私はエンジニア未経験です。現在はエンジニアへ転職活動中です。
なのでここに記載してあることは一個人の考え方・理解であり、間違っている箇所は多々あります。
とあるきっかけでこの本を買い、読んでいるので、自分なりにまとめていこうと思います。
こちらで1部 １章について記載してあります。
https://qiita.com/Hiyokokeko/items/02f4cc40dfad70dee6a6
2章 コミュニケーションと言語の使い方
この章の課題
開発者同士やビジネス側でコミュニケーションと言語をどう使っていくか？
ドメイン駆動設計はUML（統一モデリング言語）で描かれた図だけじゃない。
モデルを使ったコミュニケーションは色々な幅広い用途で使われている。
例えば、ドキュメントであったり、ホワイトボードに描いた簡素な略図であったり、
日常会話などもモデルは役立つ。
コミュニケーションがうまくいかない時
ドメインエキスパートと開発者の言葉が違ってくると、間に通訳が必要となってくる。
ビジネスに詳しい開発者に聞けば、そのことがわかったり、逆に
多少開発に詳しいビジネスの人がいて、その人に聞けばなんとかなる場合もあるけど...
それらは通訳側に余計なコストもあるし、誤解を招く場合もある。
↓よって
その通訳がいないとチームのコミュニケーションがにぶって、知識のかみ砕きができない。
↓そこで出てくるのが
「ユビキタス言語」
ユビキタス言語
ユビキタス言語とは・・・モデルに基づいた言語であり、全員で同じ言葉でコミュニケーションを行うための共通言語である。
ドメインエキスパートと開発者の間や、ドメインエキスパート同士も、開発者同士もコミュニケーションで使うべきである。
それには上記でも書いた、ドキュメントや簡略図や日常会話が含まれる。
言語が使われていけばいくほど、理解もよりスムーズなものになる！
言語を使っていく過程で、意見が食い違ってくるならお互いで新しい言葉を作成するのも！？
まあケースバイケースということで。
言語が変更されたら、クラス図やコードも含めて変更する。
ユビキタス言語の変更はモデルの変更という認識をすること。
ドメインエキスパートは理解を伝えるために使いにくかったり、不適切だったら異議を唱える。
開発者は設計を妨害することになるあいまいさや不整合を見逃さないようにする。
声に出してモデリングする
- 会話をすることで単語の解釈や意味が違っていることが自然に見つかる。
- 会話をすることでニュアンスを理解し、違いが解消される。
声に出して表現すべきことをより簡単に言う方法を見つけて、それらを図やコードにも反映していく。
１つのチームに１つの言語
ドメインエキスパートも開発者も同じ言語を使っていこう！
- 開発者だけが知っておけば良い知識（技術用語や技術のデザインパターンなど）
- ドメインエキスパートだけが知っておけば良い知識（設計に出てこない一般的なビジネス用語など）
それぞれの知識はあるけども、共通して同じ意味を持つ言葉があるなら同じ言葉（ユビキタス言語）を意識して使っていきましょうねという考え。
モデルをどうやって表現するのか
モデルは図やドキュメント（言語）やコードで表現できる。
図において
メリット・・・コミュニケーションや説明がしやすい
デメリット・・・全てを図にするのは困難である（オブジェクトのふるまいやオブジェクトに対する制約など）
説明のためにはクラス図などUMLだけでなく、視覚的にわかりやすいものを使う。
ドキュメント（言語）において
メリット・・・図で表現できないことをはっきりと伝えられる
デメリット・・・実態から取り残されてしまうことがある（コードの進化やプロジェクトで使われる言語の進化から）
ドキュメント（言語）は特に注意が必要で、なぜなら古くなりやすいから。
役に立つドキュメントを最新の状態で保つことが重要。
そのためには、ドキュメントを最小限にとどめてコードと会話の補足を目的とすること。
そうして、プロジェクトの活動に織り込まれる生きたドキュメントを作成していく。
コードにおいて
メリット・・・あいまいではない、実際の動作と結びついている
デメリット・・・背景を伝えることが困難、理解がしづらい
以上これらのメリットを活かすこと、適材適所で使っていきましょうということ。
まとめ
- 1部の中で読んでいてかなり需要な部分だと考える。
- 同じ言葉を使うようになれば、開発されているプロダクトの状況をドメインエキスパートが理解して意見することができる環境ができるのが大事。
次回は3章 モデルと実装を結びつけるを記載したいと思います。