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に集中していた処理を、明確に分散することができます。

まとめ

MVCのFat Controller問題を発端に、ADRの利点と機能を理解することができました。
次回は、実際にLaravelで実装をしてみたいと思います。