読者です 読者をやめる 読者になる 読者になる

日頃の行い

個人的な日頃の行いをつらつら書いてます\\\\ ٩( 'ω' )و ////

Domain Driven Design Quickly Onlineを読む #2

DDD 日記

www.infoq.com を読みます。

1章 Domain Driven Design Quickly Onlineを読む #1 - 日頃の行い

章ごとに雑なメモとして解説などではなく、思ったことを淡々と書いていくつもりです。

2章 ユビキタス言語

共通言語の必要性

前章おさらい
ソフトウェアの専門家とドメインの専門家が一緒に働き、ドメインモデルを作成することが不可欠

しかし、それぞれの専門とする分野の言葉をそれぞれが使おうとするため、コミュニケーションが難しくなる
部外者が理解できないような専門用語など
開発者やドメインの専門家が使う言葉を門外漢がわかるように例えた言葉であったとしてもドメインに関する知識を確立する作業には役立たない
ドメイン駆動設計の核となる原則:ドメインモデルに基づく言語を使う
コミュニケーションやプログラミングコードにもこのドメインモデルに基づく言葉を使う
このような言葉をユビキタス言語と呼ぶ

共通言語として使える用語を見つけるのは簡単じゃない
ドメインの定義と設計の方向を決めるような重要な要素を見つけ、これらの要素に適切な名前をつけることで、共通言語として使える用語が手に入る

ドメインの専門家は、ドメインモデルや共通言語の中で理解できないものがあった時は何らかの間違いがある
開発者は設計に紛れ込みやすい曖昧さや矛盾が現れていないかを注視しないといけない

この辺りでユビキタス言語を作っていくストーリーの具体例

普段の会話では婉曲的な会話になることや、詳細に立ち入りすぎること、概念を取り違えたりすることがよくある
そのような会話でユビキタス言語を見つけるのは難しい
なので、チームすべてのメンバでユビキタス言語を作らなければならないと自覚して重要な点に集中しつつ、
必要なときには既に作成したユビキタス言語を利用する
そして、このような作業時には独自の専門用語を極力使わないようにする

開発者はドメインモデルの主要な概念をコードへ実装するべき

ユビキタス言語はどのように表現すべきか
UMLも良い、文書を使っても良い
モデルについての認識を合わせるためのおすすめは、モデルの部分を表す小さな図を作成すること
これらの図は、幾つかのクラスを含み、それらの関係を表し、概念全体の一部を適切に含む
ドメインモデル全体を表す大きな図は作成できたとしても雑然としているはずなので、小さな図の集まりの方がよりよく理解できるはず

ソフトウェアアーキテクト・開発者・ドメインの専門家を含む設計チームに必要なのは、作業を統一し、モデルの作成とコーディングを助ける共通言語

まとめ

  • 開発者だけではなくドメインの専門家も含めたそれぞれの専門用語ではない共通言語(ユビキタス言語)の作成がチームでプロジェクトを進めていく上で大事
  • ユビキタス言語は図や文章様々な表現方法で、大きく全体的というより、小さな図の集合によって表すと良い