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