Fat Controllerから脱しよう！ADRについて学ぶ！

こんにちは！ドイです。

Laravelでの開発を始めて、3年が経ちました。
コードを書くことすら初めてだった私が、初めに覚えたのはMVCという概念でした。
開発を続けるうちに、小さな案件から大きな案件まで関わるようになり、少し困ったことが出てきました。
「このController、少しFatでない？」

今回は、Fat Controllerから脱すべく、ADRについて学んでみようと思います。

MVCとは

Model（モデル）、View（ビュー）、Controller（コントローラー）
それぞれの頭文字をとり「MVC」と呼ばれます。

Model、View、Controllerの3つで、それぞれ役割を分散する設計モデルです。

Model：データの取得や、登録、更新、削除などを行う。
View：ユーザーが実際に見る画面。データの出力や入力を行う。
Controller：ModelとViewの制御を行う。

アプリケーションを開発する上で、「データアクセス層」「プレゼンテーション層」「ビジネスロジック層」という言葉をよく聞きます。
3層アーキテクチャと呼ばれるものですが、MVCと合わせて考えると以下のようになります。

データアクセス層：DBに対して、データの取得や入力を行う。
プレゼンテーション層：アプリケーションとユーザーとのやり取りを行う。
ビジネスロジック層：システムのロジック処理を行う。

それぞれの役割が分散されているように思いますが、ここでFat Controller問題が起こります。

Fat Controllerとは

直訳すると「太ったコントローラー」になりますが、本来の目的以上に機能を持ちすぎて肥大した状態のControllerをこう呼びます。

MVCでは、Model、つまりデータアクセス層から受け取ったデータの加工処理をどこに記述するのか、開発者によってルールが曖昧だったり、Controllerに処理を書いてControllerのコード量が多くなったりと問題が出てきます。
MVCの問題を解決するべく、Paul M. Jones（pmjones）氏により考案されたのがADRです。

ADRとは

Action（アクション）、Domain（ドメイン）、Responder（レスポンダー）
それぞれの頭文字をとり「ADR」と呼ばれます。

MVCと同様に、それぞれ分散して役割を持ちます。

Action：DomainとResponderの橋渡しを行う。Controllerとは異なり、「1つのクラスに対して、1アクションのみを持つ」。クラスは増えるが、MVCで問題だったFat Controllerの状態を回避する。
Domain：ビジネスロジック、データの加工を行う。MVCでのModelに相当する。
Responder：Actionから受け取ったデータを、表示のため加工する。

ビジネスロジックと表示のためのデータ加工を分けることにより、MVCではControllerに集中していた処理を、明確に分散することができます。