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

例外発生時で考えるべきポイント

いままでもいろいろ考えてきましたが、例外が発生した時のポイント(あるいはその周辺)について再度考えて見ようと思います。 Contents1 トランザクションスコープ2 どんな例外をなげるか3 例外を発 …

no image

オブジェクト指向 ドメインモデル

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にドメインモデルの考え方について。 Contents1 ドメインモデルの考え方1.1 要点1.2 感想 ドメインモデルの考え …

no image

Observeパターンについて

Contents1 Observeパターン2 他の対策2.1 プログラムで頑張って制御2.1.1 メリット2.1.2 デメリット2.2 Databaseのtirggerを使う(DB更新系のみ)2.2. …

no image

オブジェクト指向設計 依存関係の管理

オブジェクト指向シリーズ。読みにくい本が多い中でオブジェクト指向設計実践ガイドは勉強になるなー。 Contents1 依存関係の管理1.1 メモ1.2 実際のコーディング上のコツ1.3 感想 依存関係 …

no image

自動テストをやる上で今まで障害だったこと

自動テストについて、考え方自体は5年以上前から知っていましたが、プロジェクトで実際に使われているのを見たのは今年4月になってからでした・・・ 自動テスト完備なんて昔は夢物語だと思ってたんですけどね・・ …

アーカイブ