SpringBoot/各レイヤの責務の履歴(No.2)

Spring Boot における各レイヤの責務†

Spring Boot (Spring MVC)における各レイヤの責務をまとめる

Spring Bootにおける各レイヤのコンポーネント (@Controller, @Service, @Repository) を設計・実装する際に，「この処理はどのコンポーネントで実装すべきなのか？」と迷うことがある．

NTTデータが出しているSpring MVCの詳細なプラクティス TeraSoluna を参考にその設計基準をまとめてみる．

File not found: "layered-architecture.png" at page "SpringBoot/各レイヤの責務"[添付]

ユーザに対して，Webアプリケーションを操作するユーザインタフェースを提供する．

Webアプリの場合，一般にHTMLで実装されるが以下の2パターンの実装がある：

我々の研究室では，クライアント側で作るほうを推奨している．これは，アプリの機能をマイクロサービス(Web-API)として，HTML以外からも呼び出したいため．

主な仕事

リクエストを受け取り処理を実行するメソッドを＠View層に提供する．

リクエスト→メソッドのマッピングや入力データチェック（バリデーション），フォームやDTOとEntityの相互変換などを行う．

Controller層の役割は業務ロジック（サービス）を利用するために必要な 前処理・後処理を行うことであり，業務ロジックそのものに関連する処理を行ってはならない．

主な仕事

アプリケーション固有の業務ロジックを実行するメソッドを@Controller層に提供する．

業務ロジックは，ビジネスルールの実行，および，それに伴う業務データの参照，更新，ビジネスルールのチェックなどで構成される．

Service層の役割は，ビジネスルールに関わる処理に専念することとし，業務データ（Entity）のDBへの出し入れはRepositoryに委譲する．

主な仕事

ビジネスルールの実行
ルールのチェックとビジネス例外のスロー
DTO ⇔ Entity変換 (業務ルールに依存する部分．Entity作成日時の付与，更新日時の付与など)
Repository経由での業務データ(Entity)の参照，更新
トランザクション境界を宣言する (@Transactional)
- 一つのメソッド内で，複数のEntityを更新する場合，すべて成功してはじめて一つの処理（＝トランザクション）の成功とする．どれかが失敗したら，なかったことにしてやり直す
- TransactionはControllerでやってはならない．Serviceの1つのメソッド内に押し込めること．

Terasoluna より

本ガイドラインでは、ControllerとServiceで実装するロジックは、以下のルールに則って実装することを推奨する。

クライアントからリクエストされたデータに対する単項目チェック、相関項目チェックはController側(Bean ValidationまたはSpring Validator)で行う。
Serviceに渡すデータへの変換処理(Bean変換、型変換、形式変換など)は、ServiceではなくController側で行う。
ビジネスルールに関わる処理はServiceで行う。業務データへのアクセスは、RepositoryまたはO/R Mapperに委譲する。
ServiceからControllerに返却するデータ（クライアントへレスポンスするデータ）に対する値の変換処理(型変換、形式変換など)は、Serviceではなく、Controller側（Viewクラスなど）で行う。