SpringBoot/各レイヤの責務の編集

[[SpringBoot]]

* Spring Boot における各レイヤの責務 [#d216c4ba]

- 2020-05-18 中村
- 2021-06-22 中村

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

Entity, DTO, Form の役割も書いておく

** 概要 [#vf3d58cb]

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

NTTデータが出しているSpring MVCの詳細なプラクティス [[TeraSoluna:http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html]] を参考にその
設計基準をまとめてみる．

** Springのレイヤード・アーキテクチャ [#bff17aa8]

&attachref(spring_layered_architecture2.png);

** ブラウザ [#a4322976]
ユーザに対して，Webアプリケーションを操作するユーザインタフェースを提供する．

主な責務
- 情報の表示
- 情報の入力
- ボタン操作
- リクエスト送信
- レスポンス受信

** ビュー [#z761da04]
ブラウザに表示するための画面を生成する．

Webアプリの場合，以下の2パターンの実装がある：
+ サーバ側でViewを生成するパターン(Thymeleaf)
-- 初等的なWebアプリで採用される．本コースで学ぶやり方
-- 実装しやすいが画面遷移を伴うためUXはイマイチ
+ クライアント側でViewを生成するパターン(HTML5+JavaScript)
-- モダンなWebアプリケーションで採用される
-- 1つのHTMLページを動的に書き換えてUXを向上．SPA (Single Page Application)
-- コントローラはRestControllerとして，画面生成せずにデータだけを返す（マイクロサービス）
--- RestControllerはブラウザ以外からも呼び出せるので，ネイティブアプリにも利用できる

** コントローラ [#l3d7850c]
Webと業務プログラムの仲立ちをする．

ブラウザからのリクエストを受け取り，業務処理を指示し，処理結果をビューに指示する

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

主な責務
- リクエストマッピング
- 入力データチェック（''バリデーション''）→ 参考：[[SpringBoot/バリデーション]]
- Form/DTO ⇔ Entity の変換 (業務ルールに依存しない範囲で)
- 業務ロジックの呼び出し（具体的な処理の中身はService層に委譲）
- 業務ロジックの結果をもとに，画面生成を指示
- 例外 → HTTPエラーマッピング (@RestControllerAdvice) [[SpringBoot/例外処理]] を参照

** サービス [#ueac7a11]
アプリケーション固有の''業務ロジック''を実行する．

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

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

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

*** 参考：ControllerとServiceで実装するロジックの責任分界点について [#n660f0ba]
Terasoluna より

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

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

** レポジトリ [#r101eea0]

業務データの操作(CRUD)を行う．

Java Beans (POJO)で保持されたEntityを，DBに入れて永続化するが，
具体的なDB操作の詳細はService層からは隠ぺいされる．(DAOのようなもの)

Repository層の役割は，以下の2つである．
+ Entityのライフサイクル(CRUD)を制御する操作インタフェースを提供すること
+ Entityiの永続化を行う処理の実装を提供すること

Springの場合，CrudRepository等の出来合いのコンポーネントが用意されているので，1や2を自力で実装する必要がない．
- 参考： [[SpringBoot/JPA]]

主な仕事
- EntityのCRUD
- カスタムクエリ
- メソッド → SQL の変換
- オブジェクト → RDBのマッピング (O/R マッピング)

** DTO, Form, Entityの区別 [#efb587b9]
- [[SpringBoot/DTO]] を参照

* 参考文献 [#bbca63fc]
- TeraSoluna ドメイン装の実装
-- http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html

タイムスタンプを変更しない