skillup

技術ブログ

アーキテクト設計全般

クリーンアーキテクチャーがらみの話題など

投稿日:2022年7月16日 更新日:

クリーンアーキテクチャに関してメモ。

自分がプログラミングを学習したのは10年ほど前ですが、当時はいわゆるMVC(Model – Controller – View)でアプリケーションを構成することが一般的でした。

で、例によってControllerやModelが膨らみましていわゆるFatController状態になりました。

当時はコードをきれいに書くなんていう概念もあまりなかったと思います。

それからいろいろな現場でいろいろなソースを書いてきました。

今(2022年7月現在)、アーキテクチャーにこだわる現場で仕事をしておりまして、議論の中、感じたことなどをメモしておこうかと思います。

ソースの構成など

現段階で上記のようなソース構成がベターなのかなと思っております。以下各フォルダの役割について。(自明なものは避けて、説明が入りそうなものに関して。)

ポイントとしては「各階層の責務を分離させる」ですかね。

Controllers

リクエストを受け付けて、レスポンスを渡すだけ。業務ロジックに関するロジックはここに書かない。

Requests

リクエストパラメーターのクラス。Controller内部で$request->all()なんて書いてましたが、そもそもControllerの内部で値を受け取る際にRequestという形で値を取得し、バリーデーション自体もここで対処してしまうほうがきれいではあります。(私は別途Formディレクトリなんてのを作ってバリデーションはここに書いてましたが・・・)

にた概念としてAPIであればレスポンスを返すResourceクラスのようなものを作ってみても良いかもしれないです。

Service

メインの業務ロジックが入る箇所です。おそらく一番判断に迷う箇所かと思います。

ポイントとしては以下のような点でしょうか。

  • 再利用できる構成を意識すること。疎結合にすること。
  • 直接SQLを書くなどモデル層に分類される処理をなるべく書かないこと。
  • S3や外部ストレージに関わる処理を書かないこと。

これ以外にトランザクションスコープをどこで定義するのか、というのも議論が分かれる箇所かと思います。

Controllerで書いてしまうと業務ロジックを入れてしまうことになり、Service層に書いてしまうと再利用ができなくなってしまいます。

現在の現場ではAction層をControllerとServiceの中に入れてトランザクションをここで貼っていますね・・・

Infra

S3やRedisなど外部サービスとの連携に関する処理はService層の中に書かず別途ここで分離した方が良いと思われます。

csvの吐き出しみたいな処理はいろんな画面で共通になることが多いので、引数をcallbackで受け付けてこの中で吐き出す・・・みたいな処理が中心になると思います。

ValueObject

コード系の文字列など。業務で重要になってくる文字列などの情報はここに。理想論を言うと電話番号やメールアドレスも全てここにまとめるようですが、そこまではコスト的にどうかな・・と思います。アプリケーションの規模との相談になるでしょう。

Model

Entityなんて呼び方をする現場もありますね。要はテーブルと1対1に近い関係になります。

SQLを各パーツは厳密にはRepository層になるかと思いますが、ここで代替してしまっても良いのではないかと思います。

ViewModel

最後にviewに渡す場合に、レンダリングで細かい表示をするような箇所の場合、テンプレートの部分にゴリゴリと条件分岐、ループなどを書くことがあったのですがNGです。

特に画面を読み込んだ時と、バリデーションなどで戻ってきた場合は変数の読み込み箇所などが大きく変わるので条件分岐が複雑になるケースが多いのですが、

最適な書き方としてはviewModelというオブジェクトでまとめこの中で条件分岐の表示処理などを記載するのが良いでしょう。

伝票や商品など情報が多く、分岐などが多くなりがちなModelで必須かとおもいます。

UseCase

議論が分かれるところかもしれません。定義をあえて決めておくと、「利用場面ごとに、どのような処理が行われるのかを明確に定義したもの」

現在の現場ではControllerを受け取り、Serviceをまとめる層を作っております。

特徴としては、

  • Controllerと1:1になる
  • 再利用性のあるビジネスロジックはなるべくかかない
  • Transcationをここに貼る

などになるかと思われます。

これがあることでUseCaseをMock化することで、ControllerのInとOutのテスト(特にリクエストパラメーターのテスト)がかきやすくなります。

命名に関して

命名に関してですが、これもこだわれるポイントがいろいろあるなあと思っております。

  • なるべくシンプルかつ統一性のある命名にする
  • オブジェクトに関しては基本名詞で動詞を入れない
  • 業務でのリソースの扱われ方に注意する
  • 汎用的になりすぎない
  • メソッドに関して重複をしない(CustomerServiceでgetCustomerDataなど)

大事なポイント

いろいろ書いてきたのですが、クリーンアーキテクチャーに置いて一番大事なのは「現場の流儀に合わせる」ですね。

別にクリーンアーキテクチャに限った話ではないのですが・・・・

先程のリンクの筆者の方も「たいていの Web 業界の現場ではオーバースペックすぎるよ」書かれてましたが、クリーンアーキテクチャに関わらず、全てのことで言えるかと思います。

制約要因として一番の要因は当たり前ですがお金ですかね。それを取り入れる工数と人員が用意できなければそもそも絵に描いた餅になってしまいます。

これまたシステム開発の現場だけに限りませんが、理想論や正論がそのまま通用する現場はほとんどないと思います。

ただ、知識として持っておかないと現段階のリスクや問題点についてわかっておかないのでやはり勉強しておく必要はあると思っています。

-アーキテクト設計全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

オブジェクト指向設計 柔軟なインターフェイス

オブジェクト指向シリーズ。今回はインターフェイスについて。 インターフェイスといっても、implementsを使った実装だけではなく、要はあるクラスが外部の窓口となるときに使うメソッドってことだと思う …

no image

HTTPリクエストの分類について(POST、PUT、PATCT)

HTTPリクエストの分類(主に更新系のもの)について。 Contents1 POST2 PUT3 PATCH POST 更新系の代表的なHTTPリクエストですね。 通常はデータの取得=GET、更新=P …

no image

ここ1年ぐらいで再確認したネタなど

今の現場では比較的、いわゆるモダンな環境で開発をしていることもあり、非常に勉強になります。 今の現場に入る前に10年近くはPHPをやっていますが、まだまだ知らないこと(といいますか新しいことがふえてき …

no image

キャッシュの使い所とメリデメに関して(主に一覧系の処理に関して)

現在のプロジェクトがかなりの規模のECサイトになるため、正確性とパフォーマンスのトレードオフなどが先日議題にあがりました。 完全なトレードオフではないのかもしれませんが、比較的あちらをたてればこちらが …

no image

abstract,interface,traitなどについて

昔はようわからなかったabstract(継承全般)、interface、traitの使い分けなどについて。 今の現場でいろいろと考えることがあり、自分なりにいろんな方の知見を共有できたので、メモしてお …

アーカイブ