これ以外にトランザクションスコープをどこで定義するのか、というのも議論が分かれる箇所かと思います。
Controllerで書いてしまうと業務ロジックを入れてしまうことになり、Service層に書いてしまうと再利用ができなくなってしまいます。
現在の現場ではAction層をControllerとServiceの中に入れてトランザクションをここで貼っていますね・・・
Infra
S3やRedisなど外部サービスとの連携に関する処理はService層の中に書かず別途ここで分離した方が良いと思われます。
csvの吐き出しみたいな処理はいろんな画面で共通になることが多いので、引数をcallbackで受け付けてこの中で吐き出す・・・みたいな処理が中心になると思います。
ValueObject
コード系の文字列など。業務で重要になってくる文字列などの情報はここに。理想論を言うと電話番号やメールアドレスも全てここにまとめるようですが、そこまではコスト的にどうかな・・と思います。アプリケーションの規模との相談になるでしょう。
Model
Entityなんて呼び方をする現場もありますね。要はテーブルと１対１に近い関係になります。
SQLを各パーツは厳密にはRepository層になるかと思いますが、ここで代替してしまっても良いのではないかと思います。
ViewModel
最後にviewに渡す場合に、レンダリングで細かい表示をするような箇所の場合、テンプレートの部分にゴリゴリと条件分岐、ループなどを書くことがあったのですがNGです。
特に画面を読み込んだ時と、バリデーションなどで戻ってきた場合は変数の読み込み箇所などが大きく変わるので条件分岐が複雑になるケースが多いのですが、
最適な書き方としてはviewModelというオブジェクトでまとめこの中で条件分岐の表示処理などを記載するのが良いでしょう。
伝票や商品など情報が多く、分岐などが多くなりがちなModelで必須かとおもいます。
UseCase
議論が分かれるところかもしれません。定義をあえて決めておくと、「利用場面ごとに、どのような処理が行われるのかを明確に定義したもの」
現在の現場ではControllerを受け取り、Serviceをまとめる層を作っております。
特徴としては、
- Controllerと１：1になる
- 再利用性のあるビジネスロジックはなるべくかかない
- Transcationをここに貼る
などになるかと思われます。
これがあることでUseCaseをMock化することで、ControllerのInとOutのテスト(特にリクエストパラメーターのテスト)がかきやすくなります。
命名に関して
命名に関してですが、これもこだわれるポイントがいろいろあるなあと思っております。
- なるべくシンプルかつ統一性のある命名にする
- オブジェクトに関しては基本名詞で動詞を入れない
- 業務でのリソースの扱われ方に注意する
- 汎用的になりすぎない
- メソッドに関して重複をしない(CustomerServiceでgetCustomerDataなど)
大事なポイント
いろいろ書いてきたのですが、クリーンアーキテクチャーに置いて一番大事なのは「現場の流儀に合わせる」ですね。
別にクリーンアーキテクチャに限った話ではないのですが・・・・
先程のリンクの筆者の方も「たいていの Web 業界の現場ではオーバースペックすぎるよ」書かれてましたが、クリーンアーキテクチャに関わらず、全てのことで言えるかと思います。
制約要因として一番の要因は当たり前ですがお金ですかね。それを取り入れる工数と人員が用意できなければそもそも絵に描いた餅になってしまいます。
これまたシステム開発の現場だけに限りませんが、理想論や正論がそのまま通用する現場はほとんどないと思います。
ただ、知識として持っておかないと現段階のリスクや問題点についてわかっておかないのでやはり勉強しておく必要はあると思っています。
クリーンアーキテクチャに関してメモ。
自分がプログラミングを学習したのは10年ほど前ですが、当時はいわゆるMVC(Model – Controller – View)でアプリケーションを構成することが一般的でした。
で、例によってControllerやModelが膨らみましていわゆるFatController状態になりました。
当時はコードをきれいに書くなんていう概念もあまりなかったと思います。
それからいろいろな現場でいろいろなソースを書いてきました。
今(2022年7月現在)、アーキテクチャーにこだわる現場で仕事をしておりまして、議論の中、感じたことなどをメモしておこうかと思います。
Contents
ソースの構成など
現段階で上記のようなソース構成がベターなのかなと思っております。以下各フォルダの役割について。(自明なものは避けて、説明が入りそうなものに関して。)
ポイントとしては「各階層の責務を分離させる」ですかね。
Controllers
リクエストを受け付けて、レスポンスを渡すだけ。業務ロジックに関するロジックはここに書かない。
Requests
リクエストパラメーターのクラス。Controller内部で
$request->all()なんて書いてましたが、そもそもControllerの内部で値を受け取る際にRequestという形で値を取得し、バリーデーション自体もここで対処してしまうほうがきれいではあります。(私は別途Formディレクトリなんてのを作ってバリデーションはここに書いてましたが・・・)にた概念としてAPIであればレスポンスを返すResourceクラスのようなものを作ってみても良いかもしれないです。
Service
メインの業務ロジックが入る箇所です。おそらく一番判断に迷う箇所かと思います。
ポイントとしては以下のような点でしょうか。