2009年5月6日水曜日

DDD Sample Application version1.1.0: ユースケースの確認

さて、まずは Sample Applicatin のユースケースを確認する。これには、実際に動かしてみるのが一番だが、そこまでするのが面倒な人のために、丁寧にもビデオが用意されている。なので、確認はこのビデオに沿って進めていきたい。

概要
細かい説明に入る前に断っておきたいのだが、このアプリケーションは the book(Evans の DDD本)で何度も例としてあげられている、積荷の出荷とトラッキングを扱ったアプリケーションがもとになっている。イメージとしては、DELL やら Amazon やらで商品を買った際に通知されてくる、配送状況確認ページを思い浮かべてもらうとわかりやすいと思う。
このアプリケーションではさらに、上記のような商品を買った側(Customer)からの配達状況の確認だけでなく、商品提供側(DELL や Amazon)による配送の手配や、配送業者による配達状況の更新までできるようになっている。最初にこれくらいのイメージを持っているとわかりやすい。
というわけで、ビデオはこれ。とりあえずは、ざっと画面のイメージだけ確認できればOK。細かい内容はこの後にも書いてます。逆に、ビデオの内容が完璧にわかれば、この後はほとんど読む必要ないです ^^;



このアプリケーションには、以下のような3つのインタフェースがある。
  • 積荷(Cargo)のトラッキングインタフェース
  • 配送予約とルートの管理用インタフェース
  • 配送状況の更新インタフェース
最初の2つは Web、3つ目には Swing によるリッチクライアントアプリケーションと、ファイルトリガのバッチアプリケーションの2種類が用意されている。

積荷のトラッキング
これは、顧客(Customer)が注文した積荷の配送状況を確認するためのもので、トラッキングIDを入力できるだけのシンプルなインタフェースになっている。ここにトラッキングIDを入力して送信すると、以下の情報が表示される。
  • 積荷の到着予定時刻
  • 現在の積荷の場所
  • 次に積荷が向かう場所
  • 積荷の配送履歴
積荷が間違って(予定とは異なるルートで)配送されてしまった場合には、画面上に「Cargo is misdirected」とエラーメッセージが表示され、次に積荷が向かう場所は表示されず、積荷の到着予定時刻は不明と表示される。また、配送履歴のうちミスがあった部分に「×」がつく。
# 実際、顧客に直接こんな情報表示するんかいなという感じがするが…。
後で出てくるのだが「配送状況の更新インタフェース」にて誤った情報を送信した場合にこのように表示されることになる。

配送予約とルートの管理
商品の配送者(DELLとかAmazonとか)が、積荷の新規登録や配送ルートの選択を行うインタフェース。以下のようなことが可能。
  • 積荷の状況確認
  • 積荷情報の更新
  • 積荷の新規登録(配送予約)
  • 積荷の配送ルート候補の検索および確定
積荷の状況確認機能では、積荷情報の一覧表示、詳細表示ができる。詳細画面では積荷情報の更新に進むことができ、配送先のみが変更できる。「モノ」を管理するための典型的なインタフェース構成で、業務システムを作ったことがある人なら見飽きているだろう。
積荷の新規登録では、一度にすべての情報を入力しきるのではなく、まずは出発地点と到着地点、そして到着デッドラインのみを登録する。この時点でトラッキングIDが払い出されるが、配送ルートはまだ決まっていない。配送ルートは、配送ルート候補の検索および確定機能で別途確定させる。

配送ルートの検索と確定は、このシステムで一番面白いところだろう。入力された情報をもとに、配送ルートの候補がいくつか表示される。管理者はこの候補を確認し、好ましいルートを選択して配送ルートを確定させる。

なお、ビデオでは到着地点の更新は実行されていないが、既に配送ルートが選択された状態で到着地点を変更しても、エラーになることもなく警告メッセージのようなものも表示されない。かなり寛容な作りなようだ。

個人的には、こんなことに興味がある。後で確認してみたい。
  • Cargoに別々の状態を持たせているのかどうか
  • トラッキングIDをどのように払い出しているのか
  • 配送ルート候補の検索で使われる、ルート選択ポリシーの種類とその扱い

配送状況の更新
配送業者(クロネコとか佐川とか)が、配送状況を随時更新するためのインタフェース。このアプリケーションはシンプルで、1画面しかない。ここに、以下のような情報を入力する。
  • 更新時刻
  • トラッキングID
  • 便(Voyage)
  • イベント発生場所のコード
  • イベントタイプ
便は必須項目ではないらしく、イベントタイプによっては必要ないようだ。例えば、工場から積荷を受け取るイベントが発生した場合、この時点では便は関係ないので入力は不要だ。

項目名に「イベント」とあるように、これは DDDのビルディングブロックの1つである「DomainEvent」を発生させるためのインタフェースであるらしい。これだけがリッチクライアントとして作られているのは、配送の現地(倉庫や船)から更新することを考えるとバーコードなどの専用端末からの更新が現実的なためで、Swingは端末を簡易にエミュレートしているのだろう。

個人的には、このあたりに興味がある。
  • バリデーションが存在しないのは、DomainEventパターンの適用によるものなのか、端末エミュレートによるものなのか

配送状況の更新(バッチ)
Swingアプリケーションとは別に、配送状況を一括更新するインタフェースも存在する。これは、タブ区切りのテキストデータが指定のフォルダに置かれると、そのデータをもとに自動的に配送状況が一括更新されるというものだ。一括更新であること以外の機能は Swingアプリケーションと同じで、テキストデータの1行として記述する項目も、Swing アプリケーションと同じ。ビデオでは、配送状況の更新インタフェースの一部として扱われている。

まとめ
というわけで、ビデオを見るとだいたい何をやっているかはつかめると思う。一応、次回以降で確認するイベントをあげておく。
  • 配送状況の詳細表示
  • 積荷の一覧・詳細表示
  • 積荷の新規登録
  • 積荷の状態更新
  • 配送ルート候補検索
  • 積荷への配送ルート設定
  • 配送状況の更新
  • 配送状況の更新(バッチ)
次回は、これらイベントの個別のハンドリング方法を確認する前段階として、アプリケーションの全体構造を確認する。

目次:
DDD Sample Application version1.1.0を確認する

0 件のコメント: