はじめに

世界の皆さんこんにちは、さばかんです。

お元気ですか？

今回は、エリック・エヴァンスのドメイン駆動設計についての本を読んでいるのでアウトプットがてら色々まとめていこうかなと思います。

以下に今回、読んでいく本のAmazonリンクを提示しておきます。

ぜひ一度読んでみてください(僕も頑張ります)

※あくま私個人というフィルターを一度通したものになっています。解釈違いなど正確に読み取れていない部分も含むかもしれないので、悪しからずご了承ください。

第2章:コミュニケーションと言語の使い方

まず、前提としてドメインエキスパートとソフトウェア開発者は、互いに独自の言語を曖昧に表現して伝え合う。

そこのコミュニケーションがうまくいかず、通訳を通して違う解釈や情報の混乱が招かれると、『言語の断裂』があり、信頼できないソフトウェアが完成する。
(人によっても語彙が変わるためニュアンスも言語も変わる)

このことからわかるように、通訳を介してコミュニケーションを取るのはあまりにも労力(コスト)とリスクがかかるというデメリットしかない側面を持ち合わせている。

そこで、ドメインエキスパートとソフトウェア開発者を含めたチームに共通の言語があればいいと感じるだろう。

それがユビキタス言語である

UML図などを含むモデルの中で明示されたルールについて議論される用語も含まれる

ドメインエキスパート同士の会話でも使用されたり、開発者でも使用される言語。

しかし、最初から完璧なユビキタス言語など存在しない

粘り強くユビキタス言語を利用していく必要がある。

粘り強く使用していくうちに、言語の食い違いや新しい単語が生まれ、より洗礼されていく。
そうして、言語に対した変更は、ドメインモデルに対する変更と認識されるようになっていく。

対象の成果物のスコープ内で基本的には会話をし、不完全と感じた場合は、懸念を表明するべき

まとめととして：
モデルを言語の骨格として使用し、チームのコミュニケーションではその言語を用いることを約束させる。そして言語を使用する上で問題があれば実験を行い洗礼していく。ユビキタス言語に基づき、クラスやメソッド、モジュールの名前を変更していく。

ドメインエキスパートは、ドメインについて理解を伝えにくかったり、不適切だと用語の構造に異議を唱えるべき。

開発者は、設計を妨害する曖昧さや不整合性に目を光らせるべき

補足：
システムについて語るときはモデルを色々試し、モデルに許された方法で概念を結び付けながら、シナリオを声に出して描写するべき。
そこで、表現するべきことを簡単に言う方法を見つけ、その新しい考え方をコードに落とし込む。

ドキュメントについて

→ 常に最新のドキュメントであるべき。そしてドキュメントはすぐに古くなりやすいので、注意して管理すべき。

他クラス図なども使用してそれぞれの役割にあったユビキタス言語の表現手法を用いりることが重要

また、ユビキタス言語が更新されているにもかかわらず、ドキュメントが古いという時やドキュメントがあっても読まれない場合もある。

その場合ドキュメントに問題がある。

原則としてドキュメントはプロジェクト活動に取り込まれていなければならない。

説明のためもモデル図はUMLをむしろしようしない方がわかりやすい場合もある。