前回のふりかえり
第8章の主旨
- ブレイクスルーとは、リファクタリングを行う中で、モデルが実際に起きていることや、ユーザーが重視するものとより深いレベルで一致するようになる現象。
第9章 暗黙的な概念を明示的にする
- 深いモデルというのは、ドメインの中心となる概念や抽象を含んでいる。
- 概念や抽象によって、ユーザーの活動や問題、その解決策に関する本質的な知識を簡潔かつ柔軟に表現できる
- 深いモデルの最初のステップ
- ドメインにおける本質的な概念を、何とかしてモデルで表現すること
- 最初、多くの概念は暗黙的で認識できない。それを明示的に表現することで認識することができるようになる
概念を掘り出すには？
隠れた概念を明らかにするには、積極的に探す必要がある。
- チームの言語に耳を傾ける
- 設計のぎこちない点やエキスパートの発言で、矛盾してそうなところを詳しく調べる
- ドメインに関する文献を読む
- 大量に実験する
(各々詳細は後述)
言葉に耳を傾ける
- ドメインエキスパートの使う言葉に耳を傾けること
- 何か複雑なものを簡潔に述べている用語はないか？
- ドメインエキスパートに言葉の選び方を正されてないか？
- 特定のフレーズを使ったときに彼らの困惑の表情が消えることはないか？
→ これらは、モデルにとって有益になりえる概念を示す手がかりになる
- 開発者とドメインエキスパートが同じ言葉で話さなくなったら、それは警告のサインでもありチャンスでもある
- ある用語が設計にないのなら、その用語を取り込むことでモデルと設計を改善することができる
ぎこちなさを精査する
- モデルに必要な概念が常に可視化されているわけではない。欠けている概念に気づけないこと、解決策が思いつかないときもある
- 設計の中でも最もぎこちない部分に注目する
→ このような時には、積極的にドメインエキスパートに参加してもらう
矛盾について塾講する
- 一人のドメインエキスパートからもたらされた情報でも、分析すれば論理的に不整合な場合もある
- プログラムの要件を掘り下げるときに遭遇するものだが、深いモデルへの大きな手掛かりになる
- ただしドメインエキスパートが事実を2つの形で記述して、それが矛盾しているのであれば何か見落としがある
- すべての矛盾に折り合いをつけるのは現実的ではないが、異なる2つの記述であっても、熟考することで両方とも現実に適用できるかもしれない
暗黙的な概念を明らかにするために
- 文献を読む
- ドメインエキスパートと話す環境を得られなくても、本を読むことでモデルの概念を探すということもできる。
- 基本的な概念や社会通念について解説している文献が役に立つ。
- 何度でも挑戦する
- モデルは試行錯誤によって構築される。最初作ったモデルをそのまま使い続けることは無いだろう
- モデルを形作るには、方向性を変えることも必要になる
- 変更のたびに深い洞察がモデルに埋め込まれる
- 設計はよりしなやかになり、変更が容易になる
明白でない概念をモデル化する
モデルを理解するには、ありがちな「名詞と動詞」ではなく、3つのカテゴリが役に立つ。
制約
- 暗黙的に語られるものが多く、これを明示的にすると設計が大幅に向上する
- 制約を独立したメソッドに分解することで、メソッドに意図の明白な名前をつけて、設計上でも制約を明示できるようになる。
- ただし、こういう時は制約を別オブジェクトにした方がいい
- 制約によってオブジェクトの責務があいまいになってしまう場合
- 制約がドメインではっきりと見て取れるのに、モデルではそうならない場合
プロセス
思ったこと・気になったこと
概念を掘り出す という節に強く共感。今までの手戻りって、システムのあるべき姿を描き切れてないことが原因なものがすごく多かった。今思い返すと、ステークホルダーを招かず、開発メンバーだけで話し合っていたことが多かった。暗黙的な概念を見つけられてなかったんだなあ。
