DDD / Deep Models

Deep Models †

要約 †

• 役に立つモデルはめったに出てこない
  • アプリケーションのドメインとニーズを理解するようになるにつれて、最初は重要そうに見えた浅いモデル要素は処分するか、それらの観点を切り替えることになるから
• 最初は思い浮かんでいなくても、問題の確信に突き進むうちに、少しずつ抽象的概念は浮かび上がってくる。
• 前術の例は、おおまかに、本の全体にわたって引用するプロジェクトのうちの1つに基づいている→コンテナ輸送システム
• この本の中の例は運送業のエキスパートでない人でも分かるように書かれているが、実際のプロジェクトでは、実用的で明晰なモデルは大抵の場合、高度なドメインとモデリングテクニックが要求される

例えば †

• そのプロジェクトは、積み荷を予約することからで配送業務が始まるので、自分達が積み荷、配送日程などについて記述することを可能にしたモデルを開発した。 これはすべて必要で役に立ったが、ドメインエキスパートは機能に不足があり不満であると感じていた。
• 結局、Knowledge crunchingを身につけた数ヵ月後に、積み荷の物質的な積み込み、および荷下し、配達の一連の作業が主として下請業者によってまたは会社の操作上の人々によって実行されたことに気がついた
  • パーティー間には、責務の一連の移動があり、プロセスは送り主→運送業者→他のローカルな運送業者→受け取り主 と現実的なワークフローで制御した。
• 今まで、大抵の場合は、承認待ちの間、積み荷は倉庫に置いてある。それ以外の時は、配達の一連の作業が行われている つまり、以前は配送日程の管理というよりも、承認書類や支払いのリリースにつながるプロセスだけだった。

• 運送業務のこのより深い見方は深く配送日程のオブジェクトの除去ではなくモデル変化を引き起こしてしまった！ （私達の、配送業務に対する見解は、あちこちにコンテナを動かすことから、積み荷についてのワークフローを意識することに変わりました。）

Knowledge crunchingは探検であり、どこで終わるであろうかを知ることができません。

担当者のつぶやき †

• Knowledge crunching...
• もう知識バリバリでいいです。
• よく分からなかったけど、途中のwhere continuous learning prepares the team members っていうのがKnowledge crunchingな気がした。
• 締め切り守れなくてゴメンナサイ

みんなの突っ込み †

まとめ (議事録) †