ブログ名

アプリケーション構成について

1. アプリケーション構成図

アプリケーションの構成は、アプリケーション層、ドメイン層、インフラストラクチャ層と3つのレイヤーを分けて構築します。

f:id:iTD_GRP:20190620233630j:plain
図1-1

2. アプリケーション層

a. Controller

Controllerは、主に以下の役割を担います。

  • 画面遷移の制御(リクエスマッピングと処理結果に対応するViewを返却する)
  • ドメイン層のServiceの呼び出し(リクエストに対応する主処理を実行する)
  • 画面の入力チェック(Formのチェックアノテーションではチェックできないもの)

b. View

Viewは、クライアントへの出力(UIの提供を含む)を担います。 HTML/PDF/Excel/JSONなど、様々な形式で出力結果を返します。

c. Form

Formは、主に以下の役割を担います。

  • HTMLのフォームを表現(フォームのデータをControllerに渡したり、処理結果をフォームに出力する)
  • 単項目の入力チェックルールの宣言 (Bean Validationのアノテーションを付与する)

d. Helper

Helperは、Controllerを補助する役割を担います。

Helperは、Controllerの見通しを良くするためのもので、Controllerの一部として扱います。 (Controller内のprivateメソッドみたいなもの)

Controllerのメインの役割は画面制御なので、 それ以外の処理(JavaBeanの変換等)が必要になったらHelperに切り出し、委譲することを推奨します。

3. ドメイン

a. Service / ServiceImpl

Service / ServiceImplは、主に以下の役割を担います。

  • 業務ロジックの実行
  • 業務データの取得、更新(Repositoryを介して、Entityオブジェクトを取得する)

b. DomainObject

DomainObjectは、主に以下の役割を担います。

  • Controllerからフォームのデータを受け取り、Serviceに渡す
  • ControllerにServiceの処理結果を返却
  • Repositoryの処理結果を保持

c. Repository

Repositoryインタフェースは、業務ロジック(Service)を実装する上で必要となるEntityの操作を定義する役割を担います。

実体はインフラストラクチャ層のRepositoryImplで実装するため、 どのようなデータアクセスが行われているかについての情報は持ちません。

4. インフラストラクチャ層

a. RepositoryImpl

RepositoryImplは、Repositoryインタフェースで定義された操作の実装を行う役割を担います。

RepositoryImplの実装はRepositoryインタフェースによって隠蔽されるため、ドメイン層のコンポーネント(Serviceなど)では、どのようにデータアクセスされているか意識しなくて済みます。

また、Entityを永続化する処理を提供します。永続先は、リレーショナルデータベースになることが多いですが、NoSQLデータベース、キャッシュサーバ、外部システム、ファイル(共有ディスク)などになることもあります。

b. O/R Mapper

O/R Mapperは、データベースとEntityの相互マッピングを担います。

MyBatis / JPA / Spring JDBCが、本機能を提供します。

具体的には、それぞれ以下の内容がO/R Mapperに該当します。

  • MyBatis3を用いる場合は、MapperインタフェースやSqlSession
  • JPAを用いる場合は、EntityManager
  • Spring JDBCを用いる場合は、JdbcTemplate

次の記事へ

前の記事へ 目次に戻る