ドメイン駆動設計読書会、第4回のメモ
【限定募集:第1回の申込者のみ、参加登録可能】第4回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper
第1章後半~第2章アタマあたりまで読んできた。この勉強会、ペースは非常にゆっくりだけど、ユビキタス言語ってどういう意味なのかとか、「厳密なモデル」が言う厳密さってどういうモノなんだよとか突っ込んでて面白い。ドメイン駆動開発というドメインについてワイワイやりながら一緒に考えてる感じがする。以下はメモなので参加した人以外には伝わらないと思うけど、これもドキュメントで全部表現するんじゃなくてコミュニケーションでモデルを深めていくDDDっぽい雰囲気がある(適当)。
第1章
隠された概念を引き出す(p.18)
- オーバーブッキングポリシーの計算を外出ししている。→すぐに分かるものかどうか?
- すぐ分かる訳ではない。本来はリファクタリングのタイミングで見出されるもの
- 原則:意図を適切な粒度で表現する。
- 図1.10のモデルは業務知識が可視化されていることがポイント。要件定義とコードの間でトレーサビリティを確保すると分かりやすくなる。
深いモデル(p.20)
- ここ重要!!一番重要by久保さん
- 業務知識が無いと、開発者が一生懸命考えてもブレークスルーで船荷証券というモデルは出てこない!プロの視点が欠けている
- (そもそも業務知識が無いとアーキテクチャが完成しないというのは正しいあり方なのか)
- PCO(経営管理用語:Policy-Control-Operation) という考え方がある。船荷証券というのは業務のエキスパートが分析を行った段階で、Control層に出てくるもの
- DDD本自体には、モデリングのやり方それ自体は16章「責務のレイヤ(p.456)」まで出てこない。
- よくいるユーザー「現状のやり方を変えたくないが、問題を解決したい」
- ユーザー自身PCO的な考え方を持っているわけではない。ユーザーにメリットがあるのなら、一緒に整理してあげる
- 実務的には上から攻めると通りやすい(下の実務者ほど、今のやり方を変えたくない傾向)
- コンサルタント:各業種のモデルのテンプレートを持っていたりする。(用語集、モデルの元ネタになる)
- 深いモデルに至るのに数カ月もかかるのはなぜ?
- 開発者が対話する顧客も末端だったりする(=業務レベルの知識しかない)。
- コンサルタントだと、より顧客の上層とコミュニケーションをとることになるので、管理レベルでモデルを考えやすいのかも
第2章
ユビキタス言語
- DB定義なんかでシノニム、ホモニム(言語と意味のn対1,1対n関係)が起きることがある
- ここで言っているのは単に用語集作ろう、ではない。辞書があれば言語がしゃべれるわけではない。単に言葉をそろえましょう、というだけの話ではない。
- ユビキタス言語を会話に使うことで、DSLのセマンティクスをテストしている -「厳密に」とは?…ユビキタス言語の属性、操作だけDSLが構成できる、ユースケースがすべて説明しきれる位の厳密さ
- すべてのコードでモデルと厳密に結びつけるのはコストかかる。ドメイン層とそうでないものを区別する
- たとえばdomainパッケージ以下はすべてユビキタス言語で使うとか
- パッケージ境界とモデル境界が一致しないことはよくある
- コンテキストをまたがったモデル
- コンテキストマップをつくる。→実装上ではインターフェースのような型の仕組みを使う。異なるモデルそれぞれで継承する、型ツリーをつくる
- 会話は日本語だけど、コードは英語が多い。どうする?
例2.1 貨物輸送プログラム(p.27)
- 太字がモデルの語彙
- 経路仕様をあえてモデルとして登場させるのは、素朴な(現実のモノをクラスに写像するような)OOPとは一線を画している。モデルの意図を明確にしようとしている
- 経路仕様クラス…ビジネスルールの検証をやっているモデル。実装上はステートレス
- 「経路仕様」はユーザがもともとメンタルモデルに持っていたのか、モデルとして見出したのか?
- この例を見ると、開発者が新しいモデルを考え出した。
- 開発者は「仕様パターン」のようなメタモデルを持っていたことで、経路仕様というモデルを思いつけた。
声に出してモデリングする(p.30)
- 自然言語の文法に乗せてはいるが、よりDSLに近くなっている。
- 「経路選択サービスは、経路仕様を満たしている輸送日程を見つける。」→ユビキタス言語で表現しきっている。
- 表現できてないなら、モデルが不十分
*1:ここでの事例→ぐるぐるDDD(ドメイン駆動設計)に参加に参加してみました