2009年5月6日水曜日

DDD Sample Application version1.1.0: アプリケーション全体構造の確認

続いては、アプリケーション全体構造の確認。ここからようやく、ソースコードレベルでの確認に入っていく。単にソースを見るだけならダウンロードページからダウンロードすればいいが、効率よく読んでいくためには Eclipse 等 IDE のサポートが必要だろう。Maven を使っているので多少面倒くさいが、ダウンロードページには IDE で使うための情報も書かれているので、(特に Eclipse ユーザーは)参考にすると良い。

インフラストラクチャが依存するテクノロジ
実際のアプリケーションに入る前に、まずはインフラが依存する基本的なテクノロジ(ライブラリやフレームワーク)を確認しておく。採用するテクノロジは列挙にとどめる。
  • IoC (DI)コンテナ
    • Spring 2.5.6
  • Webフレームワーク
    • Spring WebMVC 2.5.6
  • ORM
    • Hibernate 3.3.1
  • ロギング
    • log4j 1.2.14

パッケージの概要
アプリケーションは、大きく以下の3つのパッケージに分割されている。
  • com.pathfinder
  • com.aggregator
  • se.citerus.dddsample
com.pathfinder は配送ルート候補を計算するために使われているのだが、これは一般的なグラフ構造を扱うパッケージになっており、Distillation の観点から見ると COHESIVE MECHANISMS(一般的な問題を解決するためのメカニズムを表す部分) になっている。もしかすると、GENERIC SUBDOMAINS(ドメインの観点から見て重要性が低い部分)とみなしても良いのかもしれない。

aggregator は 配送状況を一括更新するための Java-XML マッピングと Webサービスを扱っているパッケージだが、この部分を interfaces に含めず独立したパッケージとして扱っている理由がよくわからない。Webインタフェース用の Servlet や Spring WebMVC の Controller が interfaces パッケージに含まれることを考えると、Webサービス用だけが独立しているのは理解しづらい。

se.citerus.dddsample は、CORE DOMAIN(ドメインの観点から重要度の最も高い部分)、またはCORE DOMAINを含むパッケージとなっているはずで、主要な機能はすべてここにおさめられている。

レイヤの確認
se.citerus.dddsample パッケージはさらに、以下の4つのパッケージで構成されている。
  • interfaces
  • infrastructure
  • application
  • domain
このうち、interfaces を除く3つは、the book で基本的なレイヤとして紹介されているもので、それがそのままパッケージ構造に反映されている。これらレイヤの概要は、Architectureと題されたページに書かれている。
# なお、テストパッケージにはこれらに加えて「scenario」が存在し、シナリオテストが収められている。

INTERFACES
今回から新たに導入されたレイヤ。Webブラウザ等のヒューマンインタフェースを含む、外部システムとのインタフェースすべてが配置される。入力データの解釈、検証、変換や、出力データのシリアライズはこのレイヤが担う。DTO も含まれる。
# だったらなおさら、なんで aggregator が独立パッケージなのかわからないが

このパッケージは、さらに以下の3つのパッケージで構成されている。
  • tracking
  • booking
  • handling
これは、ビデオで紹介されている主要なインタフェースに対応…つまり、 tracking が Customer による配送状況の確認に、booking が配送手配者による積荷の管理に、handling が配送業者による配送状況の更新に対応している。

これらのパッケージは、それぞれがさらにテクノロジ依存のサブパッケージ(web, file, wsなど)を持っているが、この部分の詳細は次回以降で確認する。

APPLICATION
積荷の新規登録(Booking)と配送状況更新(Handling)に関するアプリケーションサービスとその実装、それに ApplicationEvent というイベント通知用のインタフェースから構成されている。アプリケーションサービスに配送状況確認(Tracking)がないのは、おそらくシンプルすぎてサービスが必要ないからだと思われる。Tracking は参照のみなので、Repository のメソッドを呼ぶだけですんでしまう。次回参照するが、この処理は interfaces パッケージ内の Controller に直接記述されている。
ApplicationEvent はいわゆるイベントオブジェクトではなく、ステートレスなイベント通知インタフェースで、ほぼサービスと考えても良いくらいのものだ。ApplicationEvent の実装はメッセージングを使うようになっており、そのインフラ色の強さからか infrastructure パッケージに配置されている。

テストやサンプルデータ生成用のユーティリティも配置されているが、これらは本来ならテストソースフォルダなりリソースフォルダなりに移すべきものだろう。

INFRASTRUCTURE
infrastructure パッケージは、以下の3つのパッケージで構成されている。
  • persistence.hibernate
  • messaging.jms
  • routing
persistence.hibernate パッケージには、何度も the book で述べられているとおり(ドメイン層にインタフェースだけ存在する) Repository の Hibernate 実装が配置されている。

messaging.jms にはその名のとおり JMS 関連のコードが配置されており、infrastructure の観点では特に興味深い点はないが、ApplicationEvent のような application レイヤの実装も含まれている点は面白い。Sample Application 1.0 にはinfrastructure パッケージが存在せず、すべて application につっこまれていたことから、application は infrastructure-aware で良いのかと思っていたが、application もきちんとインフラから分離するようだ。

routing パッケージに唯一存在する ExternalRoutingSerivice は、なんとドメインサービスの実装だ。ドメインサービスの実装が infrastructure に配置されるなんて構成は考えたこともなかった。このサービスは、COHESIVE MECHANISMS として紹介した pathfinder へのリモート接続を含むため、infrastructure に配置されているようだ。接続先の pathfinder サービスは javax.rmi.Remote を実装しているため、RemoteException をスローする。

DOMAIN
すべての中心となる部分。パッケージは以下のように分割されている。
  • model
  • service
  • shared
model には、ENTITIES, VALUE OBJECTS, DOMAIN EVENTS, REPOSITORIES, FACTORIES といったDDDのビルディングブロックが含まれている。また、各種 Exception も含まれている。あまり説明はいらないだろう。

service には、ドメインサービスが含まれている。今回は、先ほど infrastructure で説明した RoutingService しか配置されていない。

shared には、DDDビルディングブロックを表す各種インタフェースや、Specification 関連の基本クラスなど、まさにドメインレイヤの基盤になるクラスたちが配置されている。

まとめ
まずは主要な部分である se.citerus.dddsample と補助的な部分である com.aggregator/com.pathfinder とは明確に分離できる。主要なドメインである dddsample は、(interfacesが追加されているものの)基本的には the book に忠実に分割されていることがわかる。

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

0 件のコメント: