DDD / Scrutinize Awkwardness

設計のぎこちなさを綿密に検査せよ (p.211) †

要約 †

• 210-1 (The concept you need is 〜)
  • 必要なコンセプトは簡単に見つかったり会話やドキュメント上に表れたりするとは限りません。探るべきところは、設計のもっともぎこちないところです。それは、手続き処理が説明し難い複雑なことを行っていて、また、新しい要求によって複雑さが増しそうなところです。

• 210-2(Sometimes it can be 〜)
  • 欠けた概念があることさえ認識するのが難しいことがあります。不適切な責務を持つオブジェクトに気づかなければ、何かが欠けていることを認識できたとしてもモデルの解決策が得られないこともあります。

• 211-1(Now you have to 〜)
  • 検査するには、開発者はドメイン専門家と積極的に関わらなければいけません。運がよければ、専門家はアイデアを考えたりモデルを検証することを楽しんでくれるかもしれません。しかし、運がわるければ、開発者がアイデアを考え出さなければならず、専門家は検証役を引き受けさせられて不快な顔をするかもしれません。

例 苦労して利息を得る †

扱いが難しくなってきている利息計算のモデル（Figure 9.4）ついて、開発者と専門家が協力してリファクタリングするという例。 （会話の要約は今のところ省略しています）

• 215-1（The new model has 〜）
  • 新しいモデル（Figure 9.8）はいくつかの利点を持ちます。
    • 1.「見越し額」という用語でユビキタス言語を豊かにする。
    • 2.支払いから見越し額を分離する。
    • 3.記帳される台帳といったドメイン知識をスクリプトからドメイン層へ移動する。
    • 4.ビジネスに合うように料金と利息をまとめ、コードから重複を取り除く。
    • 5.見越し額予定として手数料や利息の新しいバリエーションを追加するわかりやすい方法を提供する。

• 216-1(This time, the developer 〜)
  • 今回、開発者は利息計算のぎこちなさを認識し、より深い解を求めて最大限の努力をしました。

• 216-2(She was lucky to have 〜)
  • 開発者が知的でモチベーションの高い専門家と協力できたのは幸運でした。そのような専門家がいなければ、出だしからつまづいたでしょうし、開発者間でのブレインストーミングに頼る必要がありました。もしそうであれば、進捗は可能ではあるもののもっと遅くなっていたでしょう。

担当者のつぶやき †

みんなの突っ込み †

まとめ (議事録) †