言語を聞け (P206) †
要約 †
- 206-1 (You may remember 〜)
- このような経験があるかもしれません．ユーザはいつもレポートのある項目の話をしますが，あなたはその用語を理解しておらず，重要性を実感していません．
- 206-2 (Then suddenly 〜)
- その後，レポート上の項目の名前がドメインの重要な概念を示していることに突然気がつきます．あなたとユーザはより正確に理解し合い，ドメインモデルの言語はよりパワフルになります．
- 206-3 (Listen to the language 〜)
- ドメインエキスパートが使う言語に耳を傾けてください．
- 複雑な何かを簡潔に述べる用語がありませんか？
- あなたの言葉遣いが訂正されていませんか？
- あなたが特定の用語を使うと彼らの表情が曇りませんか？
- 206-4 (This is not the old 〜)
- ユーザやドメインエキスパートが設計にない言葉を使う時，それは警告となります．開発者とドメインエキスパートが設計にない言葉を使う時，それは二重に強い警告です．
- 207-1 (Or perhaps it is better 〜)
- もし用語が設計に含まれていないなら，それはモデルと設計を改善する機会となります．
例 輸送のモデルから失われていた概念を聞く †
- 207-1 (The team had already 〜)
- 貨物の予約システムを開発したチームは，積み荷の移動を指示する「運用支援」アプリケーションの開発を始めました．
- 207-2 (The booking application 〜)
- 予約アプリケーションは積み荷の航海を計画するためにルーティングエンジンを使いました．航海の各区間はデータベースの行として保管され，それを運ぶ船と航路や，積み荷を上げ下ろしする場所の ID を含んでいます．
- 207-3 (Let's eavesdrop 〜)
- 開発者と輸送の専門家の (かなり省略された) 会話を盗み聞きしましょう．
- 208
- 開発者
- 運用アプリケーションで必要なデータが全て「貨物予約」テーブルに揃っているか確認させてください．
- 専門家
- それには積み荷の旅程全体が必要になるね．今はどんな情報があるのかな？
- 開発者
- 貨物 ID，航路，各区間の積み込み地点と積み卸し地点です．
- 専門家
- 日付は？ 運用は予定日時に基づいた契約が必要なんだ．
- 開発者
- それは航路のスケジュールから求めることができます．テーブルのデータは正規化されています．
- 専門家
- そうか，日付が必要になることは普通だからね．運用部門はこれらの旅程を使って近日中の作業を計画するんだ．
- 開発者
- はい．．． 大丈夫です，それらは日付にアクセスできます．運用管理アプリケーションは各オペレーションの日付と共に積み込みと積み卸しのシーケンス全体を提供することができます．それは「旅程」と言うんですね．
- 専門家
- いいだろう．旅程はこれから必要となる最も重要なものなんだ．実は君も知ってるとおり，予約アプリケーションは旅程をプリントしたり顧客に電子メールするためのメニューを持っている．それを使うことができるかい？
- 開発者
- それは単なるレポートですね．運用アプリケーションのベースとすることはできません．
- 開発者
- 旅程はまさに予約とオペレーションの間の関連です．
- 専門家
- そう，そして顧客との関連もある．
- 開発者
- (ホワイトボードに図をスケッチする) それはこういうことでしょうか？
- 専門家
- そうだね，基本的に正しいように見える．各工程について，航路や積み込み，荷下ろしの場所と時間が見えるといいね．
- 開発者
- 工程オブジェクトを生成する際，航路の予定から時間を導出できます．そして旅程レポートでそれを使うように書き直せるので，ドメイン層にドメインロジックを取り戻すことができます．
- 専門家
- よく分からなかったけど，旅程の主な用途は予約のレポートと運用アプリケーションだね．
- 開発者
- キターーー！！ ルーティングサービスインタフェースはデータベースのテーブルにデータを入れるのではなく，旅程オブジェクトを返すようにできます．そうすればルーティングエンジンはこちらのテーブルを知る必要がありません．
- 専門家
- それで？
- 開発者
- つまり，ルーティングエンジンは旅程を返すだけになるんです．それは残りの予約が保存される際，予約アプリケーションで保存することができます．
- 専門家
- 今は違うのかね？
- 209 (The developer then 〜)
- 開発者は他の開発者とルーティングプロセスについて議論し，図 9.3 に到達しました．
- 210-1 (Next, the developers 〜)
- それから新しいモデルを反映するようにコードをリファクタリングしました．
- 210-2 (The developer had been 〜)
- すでに全てのデータは集まっており，振る舞いは旅程のレポート内に暗黙的に存在していましたが，旅程が明示的にモデルの一部となる機会が訪れたのです．
- 210-3 (Benefits of refactoring 〜)
- 旅程オブジェクトを明確化するリファクタリングのメリット．
- 1．ルーティングサービスインタフェースの定義をより表現力豊かにできること．
- 2．ルーティングサービスを予約データベースのテーブルから分離できること．
- 3．予約アプリケーションと運用支援アプリケーションの関係が明確になること (旅程オブジェクトは共有されます)．
- 4．予約レポートと運用支援の両方で積み込み・荷下ろしから旅程を導出することによる重複の抑制．
- 5．予約レポートからドメインロジックを削除し，独立したドメイン層に配置できること．
- 6．UBIQUITOUS LANGUAGE を拡張することにより，開発者とドメインエキスパート，または開発者同士がモデルと設計についてより正確に議論できるようになること．
担当者のつぶやき †
みんなの突っ込み †
