DDD / Walking Through Scenarios

シナリオの説明 †

要約 †

これらの全ての決定を検証するために、効果的にアプリケーションの問題を解決できるか、シナリオを通して確認してみる。

サンプルアプリケーションの機能：Cargoの目的地の変更 †

• Customerの要望で積荷の送り先を変更する必要に迫られることがある。
• Delivery SpecificationはVALUE OBJECTなので渡したり取得したり、Cargoのsetterで古いオブジェクトを新しいオブジェクトで置き換えたりすることが容易にできる。

サンプルアプリケーションの機能：業務の繰り返し †

• 同じCustomersから繰り返し予約が入った場合は似たような内容になりがち。システムのユーザは新たなCargoのプロトタイプとして古いCargoesを使いたがる。アプリケーションはCargoをREPOSITORYから見つけ出し、選択されたCargoに基づいて新しいCargoを作るよう動作する。我々はこれをPROTOTYPEパターンを使って設計する。
• CargoはENTITYであり、AGGREGATEのルートでもある。なので注意深くコピーしなければならない。各オブジェクトや属性がAGGREGATE境界の内側に存在する場合に何が起こるかを見てみる。
  • Delivery History:古いものの履歴は適用できないので、新しい空のオブジェクトを作るべき。これがAGGREGATE境界の内側にあるENTITIESの通常のケース。
  • Customer Roles：新たな積み込みで同じ役割を担うかもしれないので、Customersへのキーとなる参照を保持するMap（あるいは他のコレクション）をキーも含めてコピーすべきである。しかし、Customerそのものをコピーしないように注意する。AGGREGATE境界の外側のENTITIESなので、古いCargoオブジェクトが参照していたのと同一のCustomerオブジェクトへの参照を最終的には保持しなければならない。
  • Tracking ID：新たなCargoを作る時と同じように、新たなTracking IDを付与しなければならない。

注意：CargoのAGGREGATE境界の内側でコピーし、コピーしたものに多少の変更を加えても、AGGREGATE境界の外側には全く影響を与えていないということに注意する。

担当者のつぶやき †

• 短かったのでほぼそのまま載せてしまいました。
• 前後の文脈があまりわからずに要約しているので、変なことを書いているかも。。