05．設計1： ディレクトリ構成
概要
ディレクトリやファイルの構成を考えてみましょう！
「そんなこと必要？」と思いますか？
実は、ディレクトリやファイルの構成は、開発のやりやすさにも繋がる、とても重要なものです。
ディレクトリ・ファイル構成
以下にサンプルでの構成を記述します。
・開発（ソース）のディレクトリ
├src （WEB系のソース）
├com.sample.app.controller （コントローラのパッケージ）
├META-INF （設定ファイルの置き場所ディレクトリ※）
├log （ログ設定）
├spring （Spring設定applicationContext.xml）
├logback.xml （ログ設定ファイル）
├messages-spring_ja.properties （Springで使うメッセージファイル）
├ValidationMessages_ja.properties （妥当性エラーのエラーメッセージファイル）
├src-common （汎用的な共通系ライブラリのソース）
├src-service （ビジネスロジックとDaoのソース）
├com.sample.app.common.＊ （業務に関わる共通系のソース）
├com.sample.app.business.＊ （ビジネスロジックのソース）
├com.sample.app.dao.＊ （データアクセスのソース）
├test-src （単体テスト用のソース）
・設定ファイルのディレクトリ（WARの外部）
├tomcatホームディレクトリ（＝catalinaベース）
├app-info （WEBアプリ設定用ディレクトリ）
├sample
├logs （ログファイルの置き場所ディレクトリ）
├logback-Conf.xml （ログ設定ファイル）
├web.properties （WEB設定ファイル）
【src、src-common、src-serviceディレクトリについて】
３つのディレクトリを分けていますが、それぞれ別々のプロジェクトのイメージです。
プロジェクトを別々にしたかったのですが、サンプルとしてインストールが面倒になりそうだったので
簡便のため、１つのプロジェクトにディレクトリを分ける形にしました。
srcはWEBに関わる部分のみを置き、src-businessは、業務に関わるもののみ置き、
src-commonは、業務やWEBに無関係な、他のアプリでも使用できるような共通ライブラリを
置きました。細かく分かれています。
src-commonはJARにしてベンダ社内で配布すれば、他の開発でも使用できます。
では、src-businessとsrcはなぜ分けたのでしょうか？
それは、バッチ処理でsrc-businessを使用できるようにするためです。
バッチ処理では、WEB系のソースは不要で、含めてしまうとロードが遅くなります。
分けてJARにしておくことで、バッチ処理でもWEB処理でもそのまま利用できます。
（これも色々な考え方があるので、ひとつの考え方として捉えていただければと思います）
【META-INFについて】
上記の※META-INFに、Springの設定を置いています。
よくあるサンプルでは、Springの設定ファイルは、WEB-INFの下に置きますが、
それだと単体テスト（JUnit）でファイルを指定するのが難しくなります。
tomcatを起動したときはSpringで指定できるパスにWEB-INFが含まれますが、
JUnitを起動したときは指定できるパスに含まれないからです。
そこで、META-INFにSpringの設定ファイルを置きます。
このあたりの議論は海外のフォーラムなどでよく行われていました。
だいたい、META-INFに置くことで落ち着いてきているようです。
【設定ファイルのディレクトリについて】
本サンプルでは、tomcatホームディレクトリに外部設定ファイルを置きました。
お客様が自由にDB接続先や、ログ設定を変更できるようにするためです。
なぜtomcatホームディレクトリの配下なのでしょうか？
Springのプロパティファイルのパスの設定は以下のように記述しています。
location="file:${catalina.home}/app-info/sample/web.properties"
$｛｝は環境変数やシステムプロパティの値で置き替わります。
環境変数など使用せずに「/usr/local/app-info/web.properties」のように直接記述してもよさそうです。
しかし、そうすると、１つのOSに、１つの設定ファイルしか用意できません。
検証環境では複数のtomcatを起動して、それぞれに違うバージョンのWARファイルを置き、
別々のDBに接続したくなります。
でも、直接記述すると、すべてのtomcatで同じweb.propertiesを読み込みに行きます。
つまり、同じDBに接続してしまいます。
これを避けるために、環境変数を使用します。
tomcatは、複数ある場合、catalina.homeは別々になります。
結果、上記のlocationの記述は、同じ記述をしていても、tomcatごとに別々のディレクトリを指すことに
なります。
なんとなく、有益なことが分かっていただけたでしょうか？
この他にも${tomcat.user}を使用してtomcatごとにディレクトリを分けるなど、方法はありますので
どの方法がお客様にとって、開発者にとって良いのか？を考えながら決めていけばよいかと思います。
Created Date： 2015/03/24