とても雑なレイヤードアーキテクチャのイメージ

はじめに

レイヤードアーキテクチャが全くわからんという人向けに，とてもざっくりとしてたイメージをまとめた．

なんとなくイメージを掴んで，詳しい解説を読んだり調べたりしてほしい．

レイヤードアーキテクチャとは

レイヤードアーキテクチャ（Layered Architecture）は，システム全体を様々なレイヤー（層）に分割し，それぞれの層が特定の機能や責任を持つ設計パターンである．

各層は独立しており，下層への依存はあっても上層への依存は基本的にない．これにより，システムの柔軟性（追加や変更のしやすさ），保守性（バグが少ない，修正のしやすさ），再利用性（同じコードを書かなくて良い）が向上する．

MVC におけるレイヤードアーキテクチャ

まず，MVC フレームワークは，アプリケーションを以下の３つのコンポーネントに分ける．

コンポーネント	責務
Model	DB 操作とテーブル連携の定義を担当する．
View	ユーザーインターフェースを担当する．データを表示するための画面を作成する．
Controller	ユーザーの入力に応じた「リクエスト」「レスポンス」を担当する．

このように役割を考えると，MVC フレームワークはレイヤードアーキテクチャの考え方に基づいて設計されていることがわかる．

サービスクラスの導入

しかし，「複雑なデータが必要な場合に複数のデータを合成してデータを作成する」「取得したデータに基づいて集計や解析を行う」などの処理を担当する層がない（このような処理はビジネスロジックと呼ばれる）．これらの処理はコントローラに記述することもできるが，コントローラが肥大化してしまう．

したがって，MVC の責務に当たらない処理を担当するために「サービス層」を導入する．

サービス層はモデルとコントローラの間に位置する．コントローラからのリクエストを受け取り，必要な処理（ビジネスロジック）を実行した後，結果をコントローラに返す．

【参考】リポジトリパターンの導入

さらに，より複雑なアプリケーションの場合にはデータを DB 以外から取得する場合もある．例えば，Twitter の API からデータを取得する場合などである．

このような場合には，サービス層に加えて「リポジトリ層」を導入する．リポジトリ層を導入する場合，この層はデータソース（DB や外部の API）とのやりとりを担当する．この場合，リポジトリ層にはモデルを使用した DB からのデータ取得や API からのデータ取得を行うコードを記述する．

これにより，サービス層（ロジック担当）とデータソース間の関心の分離が達成され，よりクリーンなアーキテクチャが実現される．

まとめ（各レイヤーの役割）

各レイヤーの役割をまとめると以下のようになる．

コントローラはサービスを呼び出して使用し，サービスはリポジトリ（リポジトリを使用しない場合はモデル）を呼び出して使用する．

リポジトリはモデルを呼び出したり，その他のデータソースからデータを取得したりする．

コンポーネント	責務
View	ユーザーインターフェースを担当する．データを表示するための画面を作成する．
Controller	ユーザーの入力に応じた「リクエスト」「レスポンス」を担当する． レスポンスに必要な情報の作成はサービスクラスに任せる．
Service	取得したデータを用いたビジネスロジックを担当する． データの取得はリポジトリ層に任せる．
Repository	（DB 以外も含めて）データソースとのやりとりを担当する． DB を使用する場合はモデルに任せる．
Model	DB 操作とテーブル連携の定義を担当する．