Webアプリケーション開発において、リクエストを受けてレスポンスを返すことがサーバサイド（＝バックエンド）の仕事です。
SpringBootに限らず、どんなフレームワークを使ったとしても、サーバサイドは3層に分けてコーディングするのが一般的です。
Contents
Webアプリケーションの3層構造とは何か
次の図がWebアプリケーションの3層構造です。
プレゼンテーション層、ビジネス層、インテグレーション層の3つで構成されています。
各層の役割を概要レベルで見ていきます。
| 3層構造における層 | 役割 |
| プレゼンテーション層 | クライアントに対する入出力（リクエストとレスポンス）とビジネス層の呼び出しを担当する層。 |
| ビジネス層 | クライアントからプレゼンテーション層で受け取った値を元に、ビジネスロジック（業務処理）を実行する層。 業務アプリケーション開発の場合は、多くの場合データベース操作を伴うため、インテグレーション層の呼び出しが主な役割となる。 |
| インテグレーション層 | 「外部」に位置づけられるデータベース操作や他システムとの連携を実行する層。 MySQLやPostgreSQLなど、データベース操作が主な処理の場合は、「データアクセス層」と呼ぶこともある。 |
なぜ3層構造にするか
3層でなくても作れる
SpringBootではリクエストを受け取るためには@Controllerを付与したクラスを作成します。そして、Controllerクラスのメソッドに@RequestMapping(パス)を書けば、メソッドがパスに対する処理を行うことができます。
そのメソッド内で、業務処理やDBアクセスを書いて、そのままレスポンスを返すことができます。
この状態はControllerの1層のみで構成されていることになります。
これも不可能ではないということは知っておいてください。
なぜ、層を分けるか？
層を分けて、層ごとに役割分担させることで、コード群の見通しがよくなり、開発・保守がしやすくなります。
SpringBootで各層を実装するには
SpringBootでは、次の要領で各層を実装していきます。
| 3層構造における層 | 作成するクラス | アノテーション |
| プレゼンテーション層 | コントローラ (XxxController) | @Controller |
| ビジネス層 | サービス (XxxService) | @Service |
| インテグレーション層 | リポジトリ／DAO (XxxRepository/XxxDao) 外部接続クラス／Accessor (XxxAccessor( | @Repository/@Dao @Component |
SpringBootでは、各層を実装するためのアノテーションが用意されているので、各クラスに対してそのアノテーションを付与することで、簡単に3層構造を実現することができるようになっています。
「このコードはどの層に入れるべきか？」と迷ったら、リクエストの受付／バリデーション／レスポンスの返却はプレゼンテーション層です。データベース操作や外部APIはインテグレーション層です。それ以外は基本的にビジネス層と判断してください。適切な層にしかるべきコードが配置されていることは、コードの保守性を高め、品質を上げるという観点でとても大切です。
詳しくは各層のリンク先にあるページで解説します。
本ページのポイント
この3層構造はWebアプリケーションの最もメジャーな構造です。この構造を採用することで、どんなシステムであっても、適切にレイヤー化されたシステムとして顧客に提案することができます。今稼働しているWebアプリケーションもほとんどがこの3層構造になっているはずです。
各層の役割を明確にしたWebアプリケーションを構築することで、保守性が高くなります。