0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

はじめに

Udemyで「リバーシで学ぶアプリケーション設計入門〜仕様の整理からTypeScriptでの実装まで〜」を学びました。
この講座では主にアプリケーション設計の概念などについて色々と学ぶことができたのですが、
個人的にずっとモヤっとしていた、laravelを使用した際の設計についての解説がとても学びになりました。そこで自分なりに色々調べて得た知識とも重ね合わせて、今のところ一番いいなと思ったlaravelの設計アプローチについてoutputしておきます。

1.まずはファットコントローラーにならないように、laravelの機能を使ってコードを分割する。

・認可処理はポリシーに切り出す
・バリデーション処理はFormRequestに切り出す
・レスポンス整形処理はResourceに切り出す

2.ドメインロジックをモデルに集約する。

コントローラからドメインロジックが移植される先として挙げられやすいのがモデルです。
ただしドメインロジックをモデルで持つことでメソッド名が衝突したり、結局モデルが太ってしまうことになります。
しかしlaravelやrailsのようなMVC+ActiveRecord系O/Rマッパーでは、無理に厳格なクリーンアーキテクチャなどを持ち込まずに、アクティブレコードパターンの特性を活かすことが大事です。

*ActiveRecord系O/Rマッパーとは、
Modelというクラスが、データの入れ物兼データベースとやりとりするメソッドを持てるような設計のこと。(laravelではEloquent)

つまり、アクティブレコードのモデルの役割は以下の3つ
1.データベースのレコードと対応するデータを持つ
2.データアクセスのメソッドを持つ
3.ドメインロジックを持つ

アクティブレコード系のO/Rマッパーを使うと、このような役割をModelが持つので、
データベースとドメインロジックがくっつきます。

そのためドメインロジックがデータベースに強く依存してしまいますが、
実装量が少なくなり、早く開発できるところがアクティブレコードパターンの魅力としてあります。

以上の理由から、ドメインロジックはモデルに集約することにします。

3.ユースケースをServiceやUseCaseクラスみたいなものを使って分離する。

スクリーンショット 2023-08-17 17.31.32.png

参考

https://www.udemy.com/course/learning-application-architecture-with-reversi
https://logmi.jp/events/3690
https://zenn.dev/mpyw/articles/ce7d09eb6d8117

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?