Laravelのアーキテクチャ

概要

自分的なLaravelの運用しやすいアーキテクチャ案ができたのでメモ。 細かい部分はプロジェクトによって異なると思うので、大枠的なアーキテクチャを述べる。

自分なりの考え

LaravelではMVCとしての開発の準備が充実しているため、MVCをベースとしたアーキテクチャーについて考える。

MVCオブジェクト指向プログラミングではよく聞くWebアプリケーションの作り方であるが、Modelを効果的にデザインすることで見通しの立ちやすいコードを書くことができる。 Webアプリケーションは開発してそのまま、ということはなく機能拡張を行ったりパフォーマンスチューニングを行ったり、メンテナンスされていくものであるため、機能拡張や変更に対応していくことのできるアーキテクチャにすることが理想的である。 そのため、見通しの良いコードを書くことは機能拡張の際にも柔軟に対応することができるようになり理想に近づくことができる。

ところで、LaravelではMVCの開発の準備がされているものの、Laravel側としてはどういうMVCを構築してほしいのかを考えてみる。LaravelではControllerとViewを格納するためのフォルダは用意されている。しかしながら、Model用のフォルダは用意されていない。理由はMVCのMがどういうことをするか、どういう構成にするかは人によって異なるからである。人によっては論理操作やDB操作を単一のModelに全て押し込める人もいるだろうし、そうでない人もいるが私なりのModelデザインをこれからしていく。 一般的に、Modelで行ってほしいことは以下である。

なるべくControllerには無用に命令的なコードを書かずに、論理で追っていくことのできるスタイルが理想であると私は考えている。以降で「論理」という言葉が多用されるが、その意味は「処理を意味的なものにする」くらいに思っておいてほしいが、多分説明になっていないので下記のコードで説明する。足し算をする、というコードがあったとする。その際には、以下のように書く。

$a = 1;
$b = 2;
$result = a + b;

しかしながら、addというメソッドを用意することで以下のように書き換えることができる。

$a = 1;
$b = 2;
$result = add(a, b); // addメソッドはどこかで宣言されている

例のスケールが小さすぎるので何が嬉しいかはわかりにくいが、後者はaddメソッドによりaとbを足すんだな、と一目見ただけでわかる。このaddメソッドのように命令的な処理を関数化した、意味単位で処理のまとまりを「論理」と呼ぶことにする。

話をModelに戻す。Cotrollerではなるべく論理を利用してコードを書くために、命令的な部分(ビジネスロジックやDB操作)はModelとして水面下に隠されるべきである。

そのために、まずビジネスロジックはどのように水面下に隠すべきであるか。ビジネスロジックとはどういった存在であるかを考えると、単なる論理であるべきで、それ自身がオブジェクトになったりするものではない。そうしたことを踏まえるとphpにはtraitが使えるのでこれを使用する。traitのような論理を格納する場所はいまのところないので「Traits」や「Services」のような名前のディレクトリを作って、そこへ入れてあげれば良い。 これにより、オブジェクト指向でありながら関数型プログラミングのような論理によるコードを書くことができ、コードの見通しが立ちやすくなる。

.

├── Cotrollers
│   └── UserCotroller.php
│
├── Services(Traitsでも良いと思う)
│   └── UserService.php(UserTraits.phpでも良いと思う)

これでビジネスロジックはControllerから剥がすことができたので、次はDB処理の仕方を考える。 Laravelを利用しているのであればぜひEloquentを利用するべきである。 Eloquentでは以下のような記法でDB処理を行う(joinの例)。 我々がDBに対してjoin句を書く部分はhasOneメソッドにより論理的な操作ができるようになっている。

// 連携情報の宣言(論理の宣言)
public function foo()
{
    return $this->hasOne('連携先テーブル名');
}

// 連携情報の宣言(論理の宣言)
public function foo2()
{
    return $this-where('id' > 0);
}

// 上記の宣言を利用するためには次のようにする
$result = $this->first();
$result->foo();
$result->load(['foo2'])

// もしくは
$result = $this->with(['foo2'])->first();

これがEloquentの強みであるが、上記の一連のDB操作は大きく分けて「論理の宣言」と「利用」部分で分割することができる。 そのため、DB操作をさらに「論理」と「利用」に分けることで、DB操作の部分がごちゃごちゃしないスマートなアーキテクチャにすることができる。

これを実現するのにDBアクセスの処理をビジネスロジックから切り離す手法であるRepositroyパターンを使用する。 調べてみるとRepositoryパターンをLaravelで導入するQiita記事(これ)があるためこれを参考にして話を進める。

上記の記事では以下のような構成にしているので同じ構成にする。

.

├── Models
│   ├── User.php
│   
├── Repositories
    └── User
        ├── UserRepository.php
        └── UserRepositoryInterface.php

さて、ModelsとRepositoriesの2つのディレクトリを作成することになるが、Modelsは論理を書く場所、RepositoriesはModelsで宣言されたレゴブロックを組み立てる場所として使う。 私の中でのルールはControllerからDB処理を呼び出すのはRepositoriesであり、原則Modelを直接呼び出さない。 中には、Repositoriesなんか必要なくてControllerに書けばよい、という人もいると思う。 確かにディレクトリが増えるし、概念も増えてしまっている。しかし、残念ながら全てのDB操作がEloquentで済まない場合があったり、DB操作をチューニングして高速にしたい場合、どのようにするか。もしRepositoriesがない場合はControllerかModelsにDB処理を書くことになる。 そうすると、ControllerもしくはModelsの役割がごちゃごちゃしてしまったり、Controllerが太ってしまったり残念なことになってしまう。

結果

MVCのMをService(トレイト)とRepository(レポジトリ)とModel(Eloquentの論理宣言)の3つに分かれたが、これにより各機能が意味的に分割され、更には処理を論理的な操作で可能にすることにより、見通しが立ちやすく、保守しやすいものになった(と思っている)。

(おまけ)Laravelのここが良い

しっかりとしたアーキテクチャを構成するために使いたいLaravelの機能。

Eloquent ORM

Eloquentを利用することで見通しの良いDB操作を行うことができる。 テーブル連携では以下のように記述することができる。 引数を省略すると、自モデルの'連携先テーブル名'_idと連携先テーブルのidが紐づけられる。 第二引数と第三引数を指定することで紐づけるキーを変更することができる。 例では1対1のテーブル連携であるが、メソッドを変えることで1対多や多対多の連携もできる。

Eloquentを利用することで、処理を論理的に記述することができソースコードの見通しが良くなる。

$this.hasOne('連携先テーブル名');

また、ミューテータも非常に便利である。以下のようにgetFooAttributeというメソッドを宣言すると、first_nameへアクセスする際データはucfirstメソッドを通した形で取得することができる。 つまりDBとModelの間に立つmiddlewareのような操作をさせることができる。 今回の例ではあまり実感はないが、nullの値は空白やデフォルト文字にすることができたり 金額は税率によって変わってしまうため、middlewareで税率を積算させることができるなど、様々な箇所で便利に使えるであろう。

public function getFirstNameAttribute($value)
{
    return ucfirst($value);
}

これの逆パターンとして(getではなくset)も行うことができて、これをミューテータを呼ぶ。 例えば全部英子文字の入力を期待するが、大文字が入力された場合もミューテータを通すことにより小文字でDB登録することができる。

public function setFirstNameAttribute($value)
{
    $this->attributes['first_name'] = strtolower($value);
}

更に、Eloquentを使用して終端メソッド(getall)を利用した際はCollectionオブジェクトを取得することができる。 Collectionオブジェクトでは関数型プログラミング(のような手法)でmapやfilter等によりDBの取得結果に対して操作をすることができる。 Collectionオブジェクトを論理により操作することもまたコードの見通しを良くすることができる非常に強力な機能である。