7Laravelで複雑性と戦うための4つのTipsPHPLaravel設計Eloquent11月からオープンロジで働いている@pakkunです!入社したばかりのため、物流というドメイン知識を今必死に覚えていますアドベントカレンダーを書くと年末を感じますね!今年は、Laravelを使っていても気づいたら複雑な処理が増えている時があるなーと思い、複雑な実装になりうる課題をシンプルにする4つのTipsを書きました。個人的なTipsになりますが、この記事を読んだ方が、より早く価値が提供できるようになれば幸いです!この記事でシンプルにできるのは下記となります。複数のモデルの値を結合したい、もしくはモデルの値を使用して計算したいViewでユーザーのフルネームを表示しようとして、下記のようにUserモデルのlast_name、first_nameを使用したことはありませんか。}}</div>フルネームという言葉に着目しましょう。このフルネームというは一つの単語で表せていますので、概念として定義することができます。概念で定義できるのであれば、モデルにフルネームを取得するメソッドが定義できます。}}下記のようにモデルにロジックを集約することにより、Viewからロジックを消すことができました。}}</div>少し複雑な例で考えてみましょう。ハンバーガーセットモデルには、ハンバーガーモデル、ドリンクモデル、サイドメニューモデルがあり、その3つのモデルにはカロリー情報を持っているとします。その時にハンバーガーセットモデルにカロリーを計算するメソッドを持たせてみましょう。}}View上では計算のロジックを一切書かずに、ハンバーガーセットモデル内でカロリーを計算して、合計のカロリーを表示することができるようになりました。}}</div>Viewだけではなく、Controller、ApplicatoinService(UseCase)などでも、文字列結合や計算をしている場合、一つの概念にできないか検討しましょう。メリットとしては、モデルにメソッドとして定義できたことにより、加工や計算という処理をテストすることができるようになっています。テスタビリティが向上しています。このモデルへのロジックの定義は、ドメイン駆動設計に繋がります。ドメイン駆動設計をすべて導入するのはすごく難しいですが、このような形で少しずつ適用していくことも可能です。今回のカロリーの例では、とても単純例でしたが、食品表示としての情報にしたい場合、下記のようにValueObjectとして定義することも可能です。...}ValueObjectを使用することにより、計算や加工という処理を一つのオブジェクトに集約することができました。成分ドメイン駆動設計では、モデルを含むドメイン領域以外にビジネスロジックを定義していくことをドメインモデル貧血症と呼びます。Byした結果を表示したい!」という要望に出会ったことはあるのではないでしょうか。そんな時、SQLを使用せずに、ORMで頑張っていませんか?しかし、ORMはテーブルのツリー構造に依存しているため、ORMだけでは簡単に計算や加工を行うことができないと思います。その時は、その概念をモデルとして定義できないかを考えてみましょう!MySQLなどのRDBには、Viewを作る機能が備わっています。その機能を使用し、Eloquentモデルとして定義すれば、新しい概念をモデルとして表現できます。Viewを作るのはちょっとって思う人もいるかもしれません。