Teedaを使ったときのアーキテクチャ(クラス・パッケージ構成)

Information

Teedaを使ったときのアーキテクチャは、Super Agileの時とEasy Enterpriseの時で違います。今回は､Super Agileのケースを書いてみます。サブアプリケーションの下に存在するクラスとルートパッケージの下に存在するクラスがありますが､使い分けは次の通りです。

サブアプリケーション配下(xxx.web.yyyなど。yyyはユースケースを表す。)
- ユースケース固有のクラス
ルートパッケージのサブパッケージ配下(xxx.daoなど)
- 複数のユースケースで共通に用いられるクラス。

ユースケース固有のクラスは近くにまとまっていたほうが良く､ユースケースを横断するクラスは機能ごとにまとまっていたほうが良いという考えです。そうするとパッケージ構成は次のようになります。

xxx.web.サブアプリケーション
- Page, Dxo, DTOはここに入ります。
- ユースケース固有のロジックはPageクラスに記述します。
- DTOはユースケース固有のものと共通的なDTOの2種類があります。ここに作るのはユースケース固有のDTO。TeedaのForEach(Grid)用のDTOとか。
- Page#doXxx()にトランザクションを設定します。
xxx.entity
- テーブルに一対一にentityを作成します。
- Entity名はテーブル名と同じにします。
- 実際はテーブル名は'_'記法、Entity名はcamel 記法にします。例えば､テーブルがAAA_BBBならエンティティはAaaBbbになります。カラム名とプロパティ名の関係も同様。
xxx.dao
- Entityに一対一にDaoを作成します。
- Dao名はエンティティ名+Daoになります。
xxx.logic
- 複数のユースケースで共通に用いられるロジックを記述します。
- ロジック用のインターフェース、メソッドは次のようにして見つけます。
  - アクティビティ分析をします。
  - 個々のアクティビティを「xxxをyyyする」という形で記述します。
  - xxxがロジック用のインターフェース名になり、yyyがメソッド名になります。
- Logicで扱われるデータは､DTOではなくEntityです。
- 一般的にはLogicにDaoがDIされるでしょう。
xxx.dto
- 複数のユースケースで共通に用いられるDTOを記述します。
xxx.helper
- ユーティリティ用のクラスですが､パラメータ的な設定項目があったり､他のクラスをDIする必要があるもの。
xxx.util
- staticなメソッドで実現できるユーティリティクラス。