バックエンドのディレクトリ構成について

この記事について

バックエンドを勉強の備忘録です。
バックエンドのディレクトリでよく出てくるディレクトリ名についてまとめてみました。

Controller（コントローラー）

役割: Model と View を仲介し、アプリケーションのフロー制御を担当

• ユーザーからのリクエストを受け取る
• 適切な Service を呼び出す
• 処理結果を View に渡す
• HTTP リクエストのルーティングとレスポンス生成

Service（サービス）

役割: ビジネスロジックの実装とドメインルールの適用

• 複数のリポジトリを調整して、複雑なビジネスロジックを実装
• トランザクション管理
• ドメインロジックの実装
• コントローラーとリポジトリの間の仲介

Repository（リポジトリ）

役割: データの永続化層とのやり取りを抽象化

• データアクセスロジックをカプセル化
• データベースや API などとのやり取りを担当
• ドメインオブジェクトと永続化層の変換
• SQL クエリの実行や ORM の利用

Model（モデル）

役割: データとビジネスロジックを表現する

• データの構造と属性を定義する
• データの検証ルールを含む
• アプリケーションのビジネスルールを表現する

各コンポーネントの関係性

上記に加えてクライアントサイド( View )も含めるとアプリケーションのデータフローは通常次のようになります

1. User → View: ユーザーが UI で操作
2. View → Controller: リクエストがコントローラーに送信される
3. Controller → Service: コントローラーがサービスを呼び出す
4. Service → Repository: サービスがリポジトリを使用してデータ操作
5. Repository → データベース: リポジトリがデータベースと通信
6. Repository → Service → Controller → View → User: 結果が逆順に返される

まとめ: 各層の責任範囲

View も含めると以下のようになります。

• View: ユーザーインターフェースとデータ表示

• Controller: リクエスト処理とフロー制御

• Service: 複雑なビジネスロジックの実装

• Repository: データアクセスの抽象化

• Model: データ構造とドメインルール

  以上を分離することにより、テスト容易性、保守性、再利用性が向上し、関心の分離（Separation of Concerns）が実現できます！