Infrastructure層は「技術的な詳細」を引き受ける場所
これまでの記事で、 ドメイン層とApplication層の役割を整理してきました。
では、DBや外部API、ファイル操作といった 技術的な処理は、 どこに置くのがよいのでしょうか。
その受け皿となるのが、 Infrastructure層です。
Infrastructure層が担当するもの
Infrastructure層は、 アプリケーションを動かすための 技術的な詳細を担当します。
具体的には、次のようなものです。
- データベースへのアクセス
- 外部APIとの通信
- ファイル入出力
- メール送信やメッセージング
これらは、 業務ルールそのものではありません。
なぜ業務ロジックと分離するのか
DBや外部サービスは、 仕様変更や差し替えが起きやすい部分です。
もし業務ロジックの中に、 直接DB操作やAPI呼び出しを書いてしまうと、 技術変更の影響が 業務ルールにまで波及してしまいます。
Infrastructure層に閉じ込めることで、 業務ロジックは 技術的な変更から守られます。
Repositoryという考え方
Infrastructure層を語るうえで、 よく登場するのが Repositoryという考え方です。
Repositoryは、 「データの保存や取得の方法」を 業務ロジックから隠すための仕組みです。
ドメイン層やApplication層は、 「どう保存されているか」を知らずに、 データを扱えるようになります。
ここでは詳しい実装には踏み込みませんが、 依存の向きを逆転させる ための重要な役割を持っています。
Infrastructure層が太ると何が起きるか
Infrastructure層に 業務判断を書き始めると、 再び設計は崩れ始めます。
- SQLの中に業務ルールが埋もれる
- API呼び出しの条件分岐が複雑化する
- 修正時に影響範囲が読めなくなる
Infrastructure層は、 あくまで技術の詳細を扱う場所です。
まとめ
- Infrastructure層は技術的な処理を引き受ける層
- 業務ロジックからDBやAPIを切り離す
- Repositoryは依存を逆転させるための考え方
※ 参考：MVCの全体像から振り返りたい場合はこちら
▶ MVC学習シリーズ 目次
0 件のコメント:
コメントを投稿