DDD / III-Deep Models

Deep Models (p.189) †

要約 †

• 要件の中で名詞と動詞を探してそれをクラスとメソッドにするという古典的な手法は、入門としては悪くないが、実際にはそうやって出てきたモデルは浅い知識に基づいていて、表面的だしナイーブだ。
• 例えば、前の運送アプリケーションでは、当初「船」と「コンテナ」を含むモデルを作ったが、実際の業務には使えないことが分かった。
• 何ヶ月かのイテレーションの結果として、全く異なるモデルができあがった。これは積荷の運搬という業務に改めて焦点をあてたものだ。
• 「船」は消えたわけではないが、「航海("vessel voyage")」と言う形に抽象化されている。「コンテナ」はモデルから消え、より複雑な形となって登場している。積荷の物理的な移動よりも、積荷に対する法的責任の所在が移動することの方が重要になった。
• モデラーが新しくプロジェクトに配属されたら、「船」と「コンテナ」がないと言うだろう。それは彼らに非があるのではなく、発見のプロセスを体験していないだけだ。
• 深甚なモデルはドメイン・エキスパートの主要な関心事と現実的な価値を持つ知識を明晰に表現したものだ。そのためドメインの表層的な側面ははぎ捨てられている。これは単なる抽象化というものではない。
• 多くの用途に用いることができ、単純で、描写力があるモデルはドメインと密接に絡み合っているのであり、そういうモデルはビジネス・エキスパートが好んで使うような単純で時に抽象的な言語を含んでいるのだ。

担当者のつぶやき †

• 「深甚なモデル」っていいですね。小林さんから頂きました。
• アウトプットから固めていくというウォーターフォール的な手法だとなかなかたどり着くことができなかったり、特にたどり着く必要もない領域だったりすると思います。
  • アウトプットだけを見てても仕様が複雑すぎて、どうにも実装ができそうにない、という瞬間に発生する「そもそもこれって何をやる業務なの？」という疑問が、この「深甚なモデル」への糸口であるような気がします。
  • 現場にはどんな複雑な仕様も鬼のようなif文で実装してしまうスーパーＰＧさんがいたりしますが・・・

みんなの突っ込み †

• 無理言ってごめんなさい．「Deep Model/Supple Design」は自分の方でやっておきます． -- koichik? 2008-11-29 (土) 02:50:35
• 助かりました^^かたじけない。 -- 和智? 2008-11-29 (土) 08:12:34

まとめ (議事録) †