続いては、アプリケーション全体構造の確認。ここからようやく、ソースコードレベルでの確認に入っていく。単にソースを見るだけならダウンロードページからダウンロードすればいいが、効率よく読んでいくためには Eclipse 等 IDE のサポートが必要だろう。Maven を使っているので多少面倒くさいが、ダウンロードページには IDE で使うための情報も書かれているので、（特に Eclipse ユーザーは）参考にすると良い。
インフラストラクチャが依存するテクノロジ
実際のアプリケーションに入る前に、まずはインフラが依存する基本的なテクノロジ（ライブラリやフレームワーク）を確認しておく。採用するテクノロジは列挙にとどめる。
パッケージの概要
アプリケーションは、大きく以下の3つのパッケージに分割されている。
aggregator は 配送状況を一括更新するための Java-XML マッピングと Webサービスを扱っているパッケージだが、この部分を interfaces に含めず独立したパッケージとして扱っている理由がよくわからない。Webインタフェース用の Servlet や Spring WebMVC の Controller が interfaces パッケージに含まれることを考えると、Webサービス用だけが独立しているのは理解しづらい。
se.citerus.dddsample は、CORE DOMAIN（ドメインの観点から重要度の最も高い部分）、またはCORE DOMAINを含むパッケージとなっているはずで、主要な機能はすべてここにおさめられている。
レイヤの確認
se.citerus.dddsample パッケージはさらに、以下の4つのパッケージで構成されている。
# なお、テストパッケージにはこれらに加えて「scenario」が存在し、シナリオテストが収められている。
INTERFACES
今回から新たに導入されたレイヤ。Webブラウザ等のヒューマンインタフェースを含む、外部システムとのインタフェースすべてが配置される。入力データの解釈、検証、変換や、出力データのシリアライズはこのレイヤが担う。DTO も含まれる。
# だったらなおさら、なんで aggregator が独立パッケージなのかわからないが
このパッケージは、さらに以下の3つのパッケージで構成されている。
これらのパッケージは、それぞれがさらにテクノロジ依存のサブパッケージ（web, file, wsなど）を持っているが、この部分の詳細は次回以降で確認する。
APPLICATION
積荷の新規登録（Booking）と配送状況更新（Handling）に関するアプリケーションサービスとその実装、それに ApplicationEvent というイベント通知用のインタフェースから構成されている。アプリケーションサービスに配送状況確認（Tracking）がないのは、おそらくシンプルすぎてサービスが必要ないからだと思われる。Tracking は参照のみなので、Repository のメソッドを呼ぶだけですんでしまう。次回参照するが、この処理は interfaces パッケージ内の Controller に直接記述されている。
ApplicationEvent はいわゆるイベントオブジェクトではなく、ステートレスなイベント通知インタフェースで、ほぼサービスと考えても良いくらいのものだ。ApplicationEvent の実装はメッセージングを使うようになっており、そのインフラ色の強さからか infrastructure パッケージに配置されている。
テストやサンプルデータ生成用のユーティリティも配置されているが、これらは本来ならテストソースフォルダなりリソースフォルダなりに移すべきものだろう。
INFRASTRUCTURE
infrastructure パッケージは、以下の3つのパッケージで構成されている。
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
すべての中心となる部分。パッケージは以下のように分割されている。
service には、ドメインサービスが含まれている。今回は、先ほど infrastructure で説明した RoutingService しか配置されていない。
shared には、DDDビルディングブロックを表す各種インタフェースや、Specification 関連の基本クラスなど、まさにドメインレイヤの基盤になるクラスたちが配置されている。
まとめ
まずは主要な部分である se.citerus.dddsample と補助的な部分である com.aggregator/com.pathfinder とは明確に分離できる。主要なドメインである dddsample は、（interfacesが追加されているものの）基本的には the book に忠実に分割されていることがわかる。
目次：
DDD Sample Application version1.1.0を確認する
インフラストラクチャが依存するテクノロジ
実際のアプリケーションに入る前に、まずはインフラが依存する基本的なテクノロジ（ライブラリやフレームワーク）を確認しておく。採用するテクノロジは列挙にとどめる。
- 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
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
# なお、テストパッケージにはこれらに加えて「scenario」が存在し、シナリオテストが収められている。
INTERFACES
今回から新たに導入されたレイヤ。Webブラウザ等のヒューマンインタフェースを含む、外部システムとのインタフェースすべてが配置される。入力データの解釈、検証、変換や、出力データのシリアライズはこのレイヤが担う。DTO も含まれる。
# だったらなおさら、なんで aggregator が独立パッケージなのかわからないが
このパッケージは、さらに以下の3つのパッケージで構成されている。
- tracking
- 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
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
service には、ドメインサービスが含まれている。今回は、先ほど infrastructure で説明した RoutingService しか配置されていない。
shared には、DDDビルディングブロックを表す各種インタフェースや、Specification 関連の基本クラスなど、まさにドメインレイヤの基盤になるクラスたちが配置されている。
まとめ
まずは主要な部分である se.citerus.dddsample と補助的な部分である com.aggregator/com.pathfinder とは明確に分離できる。主要なドメインである dddsample は、（interfacesが追加されているものの）基本的には the book に忠実に分割されていることがわかる。
目次：
DDD Sample Application version1.1.0を確認する
コメント