Application層は「処理の流れ」を表す場所
前回の記事では、 ドメイン層が 業務ルールを守るための中心 であることを整理しました。
では、その業務ルールを 「いつ・どの順番で・どう使うのか」 は、どこで表現すればよいのでしょうか。
その役割を担うのが、 Application層です。
ユースケースという考え方
Application層を理解するうえで、 欠かせないキーワードが ユースケースです。
ユースケースとは、 「ユーザーが何をしたいのか」 を表した処理の単位です。
たとえば次のようなものです。
- 注文を確定する
- 会員情報を更新する
- 支払いを完了させる
Application層は、 これらのユースケースを コードとして整理する場所 と考えると分かりやすいでしょう。
Application層が担当すること
Application層の主な役割は、 次のようなものです。
- 処理の流れを組み立てる
- ドメイン層の呼び出し順を制御する
- トランザクションの境界を意識する
ここで重要なのは、 Application層自身は 業務ルールを持たない という点です。
業務として正しいかどうかの判断は、 あくまでドメイン層に任せます。
Controllerとの違い
よくある疑問が、 「それってControllerと何が違うの？」 という点です。
Controllerは、 リクエストやレスポンスを扱う 入口の役割でした。
一方、Application層は、 画面やAPIの形式に依存しない形で、 処理の流れそのもの を表現します。
実務では、 Controllerが太り始めたら、 「この処理はApplication層に移せないか？」 と考えると整理しやすくなります。
Application層があることで何が楽になるか
Application層を設けることで、 次のようなメリットがあります。
- 処理の流れが一箇所にまとまる
- 画面やAPIが増えてもロジックを再利用できる
- テストしやすくなる
特に、 同じ業務処理を 複数の画面やAPIから呼び出す場合、 Application層の存在が効いてきます。
まとめ
- Application層はユースケースを表現する層
- 処理の流れを整理し、業務ルールは持たない
- Controllerが太り始めたら切り出しを検討する
※ 参考：MVCの全体像から振り返りたい場合はこちら
▶ MVC学習シリーズ 目次
0 件のコメント:
コメントを投稿