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層になるかと思いますが、ここで代替してしまっても良いのではないかと思います。

UseCase

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

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

特徴としては、

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

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

命名に関して

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

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

大事なポイント

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

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

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

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

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

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

-アーキテクト設計全般

執筆者:


comment

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

関連記事

no image

オブジェクト指向 プレゼンテーション層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。 Contents1 プレゼンテーション層の考え方1.1 要点1. …

no image

アプリケーションアーキテクチャについて 〜既存のMVCに関して〜

今回はアプリケーションのルーター以降のアーキテクチャに関して。主にMVCなどについて説明したいと思います。 Contents1 MVC(Model,Controller,View)1.1 トランザクシ …

no image

オブジェクト指向 クラスの設計と業務ロジックの整理

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にクラスの作り方について。 Contents1 クラス設計と業務ロジック1.1 要点1.2 感想 クラス設計と業務ロジック …

no image

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

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

no image

オブジェクト指向 アプリケーション間連携(主にWebAPI)

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。 Contents1 アプリケーション間連携(主にWEBAPIに関 …

アーカイブ