Asakusa Frameworkを使ったアプリケーションを作っていく手順と構成のメモ。
Asakusaアプリケーション（Asakusa Frameworkを使ったアプリケーション）を一から実装する際に、必要となる設定があるのでまとめてみた。
前提は以下のようなもの。
開発環境は、Eclipseプラグイン（Shafu）が提供されているので、Eclipseを使うのが便利。
最初の一人がAsakusaプロジェクトを作ってGitにコミットし、他の開発メンバーがGitでチェックアウトするのが良いと思う。
この場合、各開発メンバーの開発用PCにEclipseとShafuをインストールする。
実行環境の構築はまた別。
→運用環境の構築
Asakusa FrameworkはGradle（build.gradle）で環境を構築できるようになっている。
しかしShafu（Eclipseプラグイン）が提供されているので、Eclipseで開発環境を構築し開発するのが便利だと思う。
（Shafuも内部ではGradleのコマンドを実行している）
それと、拙作DMDL EditorX（Eclipseプラグイン）もインストールしておいた方が断然便利。
Shafuを使って、Asakusaプロジェクト（Eclipseの新規プロジェクト）を作成する。
Shafuを使ってAsakusaプロジェクトを作る場合、プロジェクトのテンプレートを指定する。（テンプレートからプロジェクト構成が作られる）
テンプレートは、AsakusaFWのバージョンと実行基盤によって分かれている。
AsakusaFWのバージョンは、2021年時点ではAsakusa Framework 0.10.4が最新なので、それを使うのが良いだろう。
（バージョンを後から変えるにはマイグレーション作業が必要となる場合があり、面倒）
実行基盤は、2021年時点ではSparkかM3BPの二択だろう。
これは後から簡単に変えられる（追加も混在も出来る）ので、どちらもでいい。
Asakusaプロジェクトをテンプレートから作成すると、build.gradleが用意されている。
その中のgroupが、AsakusaFWでクラスを生成したときのパッケージ名になるので、これは一番最初に変えておく。
（後からパッケージ名を変えるのはかなり面倒なので）
group 'com.example'
これを変更したら、Eclipseのプロジェクト情報を再構築する必要がある。
それと、個人的にはEclipseのソースコードのフォーマッターを修正したい。
インデントをスペース4個にするのと、1行が長いときに折り返す文字数（デフォルト120）を増やす。
フォーマッターはエクスポートすることが出来るので、エクスポートしたxmlファイルもGit管理下に置き、開発メンバー全員で同じフォーマッターを使用する。
作成したAsakusaプロジェクトをGitで管理するようにする。
cd Asakusaプロジェクトのディレクトリー git init
.gitignoreを作り、不要なファイルを除外するようにしておく。
.gradle/ /bin/ build .project .classpath .factorypath .settings
.gradleは、Gradleの設定が入っているディレクトリー。それぞれの環境で再構築するので、Git管理は不要。
binは、Eclipse上でコンパイルした際のclassファイルが出力されるディレクトリー。
buildは、Asakusaアプリをビルドした結果が出力されるディレクトリー。
.project, .classpath, .factorypath,
.settingsはEclipseの設定。それぞれの環境で生成しなおすので、Git管理は不要。
既にGitで管理されているAsakusaプロジェクトは、以下の手順でEclipseにインポートする。
Asakusaアプリケーションの開発は、データモデル（クラス）を作らないと始まらない。
データモデルクラスはDMDLで生成する。
DMDLは拡張子dmdlのテキストファイルに記述する。
dmdlファイルを置く場所は「Asakusaプロジェクト/src/main/dmdl/」だが、その直下にファイルを置いていくと大量になるので、サブディレクトリーを作るべき。
Asakusaアプリの開発としてよくあるのが、RDBMSを使った既存システムをAsakusaFWに置き換えていく形だと思う。
その場合、ひとつのテーブル（やビュー）がひとつのデータモデルになるだろう。
dmdlファイル内には複数のデータモデルを書けるが、ひとつのDBスキーマをひとつのdmdlファイルにして中に複数テーブル（データモデル）を書くと、ファイルが膨大なサイズになってしまう。
複数の開発者が同じdmdlファイルに新テーブルを追加して競合することも多いので（特に開発序盤は）、DBスキーマ毎にサブディレクトリーを作り、テーブル毎にdmdlファイルを作る方が良いと思う。
また、テーブルのデータモデルとは別にアプリケーションの中間データを扱うためのデータモデルを定義するので、それもテーブル用と分けた方がいい。
他にも、データ受け渡し用のcsvファイル等があるなら、それも別ディレクトリーにした方がいいだろう。
すると、以下のような感じのディレクトリー構成となる。
ちなみに、データモデル名には英小文字と数字（とアンダースコア）しか使えないが、dmdlファイル名には日本語も使える。
（とはいえ、Git管理上で日本語ファイル名を使うのは不安があるが(苦笑)）
DMDL（データモデル）は、namespaceという属性を使ってサブパッケージ名（Javaのクラスが生成されるときのパッケージ名の一部）を指定することが出来る。
dmdlファイルを置いたサブディレクトリー名を指定しておくのが良いと思う。
"バッチ1のデータモデル"
@namespace(value = app.batch1)
batch1_tmp1 = {
〜
};
RDBのテーブル用のDMDLを書くのは、実業務ではテーブル数やカラム数が多いので、かなり大変。
実業務ではテーブル定義をExcelで管理していることが多いだろうから、Excelからテーブル用のdmdlファイルを生成する方が楽だと思う。
→DMDLのコンパイル（dmdlファイルからクラスを生成する）
DMDLを書いてデータモデルクラスを生成したら、次はOperatorクラスを記述する。
そのOperatorのメソッドを使ってFlowPartやJobFlowを記述し、最後にBatchを記述する。
JobFlowを記述する際にはImporter/Exporterも作っておく必要がある。
Operator・FlowPart・JobFlow・Importer/Exporter・BatchはJavaのクラスなので、パッケージ構成を考える必要がある。
（Javaのパッケージ構成は大昔（Strutsの時代）から悩みの種で、大きくは、クラスの種類毎に分ける・アプリケーションの単位（機能）毎に分けるの2種類が考えられる）
AsakusaFWではクラスの種類毎にパッケージを分けるのが主流なようだ。（AsakusaFWのサンプルプロジェクトがそういう構成になっている）
ただ、サンプルプロジェクトではImporter/ExporterがJobFlowと同じパッケージの下に入っていて、これでは数が増えたときに分かりにくいので、Importer/Exporter用のパッケージを作るべきだと思う。
サンプルプロジェクトに倣えばImporter/ExporterのパッケージはJobFlowの下の位置になるべきかもしれないが、JobFlowと同列の位置でもいいかもしれない。
すると、以下のような感じのディレクトリー・パッケージ構成になるんじゃないかと思う。
flowpartやoperatorの下はバッチ毎にパッケージを分けているが、jobflowは分けていない。
ほとんどの場合は1バッチにつきジョブフローは1つなので、jobflowのパッケージを分けるのはあまり必要が無いと思う。
port（Importer/Exporter用のパッケージ）の下は、DMDLのディレクトリー構成と同様の構成にするのが分かりやすいのではないかと思う。