ソフトウェアアーキテクチャについてLaravelと関連付けてみた

普段はLaravelを使ってWebシステムの開発をしているのですが、
システム開発をしていると嫌でも耳にするアーキテクチャという言葉を自分なりに噛み砕いてみました。

アーキテクチャとは

そもそもアーキテクチャの定義とは基本設計や設計思想を指すとのこと。
種類も調べ上げたらキリがないのですが、一旦システム開発に関わる上では以下の5パターンを把握していたら問題なさそうです。

・ソフトウェアアーキテクチャ
　→システム開発における構築方式と規律を定めたもの

・システムアーキテクチャ
　→OS、セキュリティ設定など、開発の基盤となる要素の設計

・エンタープライズアーキテクチャ
　→システムとビジネス目標を効果的に連携させるための構築方式

・ITアーキテクチャ
　→インフラ、DB、アプリケーションの最適化をするための構築方式

・ビジネスアーキテクチャ
　→組織構造や業務プロセスの最適化をするための構築方式

システム開発者の中でよく言われるアーキテクチャとは一般的にソフトウェアアーキテクチャに含まれるらしいです。

ソフトウェアアーキテクチャって？

※参考サイト
https://qiita.com/ShigemoriMasato/items/2716d3a38c75796d43fd

参考サイトから読み解くに大きく以下の3つから構成されるらしいです。

• 非機能要件
  • 拡張性、保守性を高める
  • パフォーマンス改善
• 構造
  • モジュール分割、コンポーネント設計
• ルールとガイドライン
  • コーディング規約
  • テスト方針の決定

聞いたことはある言葉だけど具体的なイメージが湧かない。。。
Laravelを結びつけるならそれぞれ以下の通りに実装すればいいらしいです。

• 非機能要件
  • 拡張性、保守性を高める：Interfaceの使用やUsecaseクラスを用いることで変化に強いソースコードを実現すること。
  • パフォーマンス改善：キャッシュの利用（view:cacheコマンドやroute:cacheコマンドなど）、composerパッケージの最適化（未使用のパッケージは削除して依存関係を少なくすること）
• 構造
  • モジュール分割、コンポーネント設計：ServiceクラスやUsecaseクラスなどのビジネスロジックや共通化クラスの生成を指す
• ルールとガイドライン
  • コーディング規約：メソッド名を特定のルールに統一するなど
  • テスト方針の決定：機能テストとユニットテストをしっかり定義付けして運用すること
    • 機能テスト：ControllerのDBアクセスを伴うテストでAPI疎通を確認する目的で使用。
    • ユニットテスト：ビジネスロジックのテストでDBアクセスも含めて処理の正常性を検証する目的で使用（ServiceクラスやUsecaseクラスの検証に有効）。

要はソースコードの解読が容易になり、拡張の容易性とシステムの品質を確保することが目的となるのかなと思います。
上記の要件を満たす上で有効的な手法の1つにクリーンアーキテクチャというものが該当します。

クリーンアーキテクチャ

うん。パッとみても分からないですね。。。笑

https://qiita.com/ucan-lab/items/a9a5c55ce12a6d8752d3

こちらの方の記事がすごくわかりやすかったので、こちらを参考に読み解くと、DDDをベースに構成を決める構築方式らしく、ビジネスロジックをフレームワークに依存しない書き方ができるため、ユニットテストの容易性も向上できるとのことです。

もう少し具体的に掘り下げてみると、大きく4つの層に分けてプロジェクトの構成を作ることがクリーンアーキテクチャの肝になるみたいです。

1. ドメイン層

   • プログラムを適用する対象となる業務知識を指し、その業務知識ごとにクラスを作成する作業を指します。
     ※よくEloquentのModelと混同しがちですが、これは全くの別物になります。ここではわかりやすくDomainのModelクラスと定義します。
   • 例）会計システムにおける「金銭」や「振込処理」など。1つのテーブルで表現できるとは限らない。
   • フレームワークに依存するのはNG。

2. アプリケーション層

   • ビジネスロジックの記述箇所で、ドメイン層とインフラ層の橋渡しを実施する。
     ※DTO（※1）を使用してビジネスロジックに必要なパラメータの定義と、ビジネスロジック実行後に返されるレスポンスの定義を実施する。
   • フレームワークに依存するのはNG。
   • LaravelにおけるServiceクラスやUsecaseクラスをイメージすればOK。

3. プレゼンテーション層

   • ユーザーからの入力を受け取り、アプリケーション層に渡し、その結果を整形してレスポンスとして返す。
   • フレームワークに依存してOK。
   • LaravelにおけるControllerやConsole（コマンド）をイメージすればOK。

4. インフラ層

   • アプリケーションがデータベースや外部システムとやり取りするための処理を実装。ここにはDomain層のクラスやEloquentのModelが処理に使用される。
     ※パラメータやレスポンスの型定義は基本的にDomainを使用する。
   • フレームワークに依存してOK。
   • LaravelにおけるRepositoryクラスの実装クラスをイメージすればOK。

※1 DTO：データの受け渡しを制限できる手法のこと。

記事を読んでいた時にフレームワーク(Laravelとか)に依存してOKだとか依存したらダメだとかルールがあるのって何故だろうと思って気になったのですが、クリーンアーキテクチャの重要性って実はここにあります。

フレームワークに依存しないということは、Laravelが独自に持つクラスファイルを一切使用しないことを指してます。(つまりLaravelのクラスファイルに依存しないことになります。)
なので、仮にLaravelがサポート終了となって他のPHPフレームワークに移行しないといけないってなった時に、その部分のクラスファイルは一切修正を加えずに別のフレームワークに持っていくことができるんです。
※イメージとしては下記の図の通りとなります。

よくアーキテクチャを勉強すると変化に強いソースコード管理になると言う言葉を耳にしますが、それは突き詰めればフレームワークを変更することさえも容易にできる究極の管理手法だと思えばその凄さはグッと分かりやすいですよね。

ただ上記に書いたクリーンアーキテクチャはゴリゴリの静的型付けを求められる要素が強く、Laravelには少しだけ導入ハードルが高いのかなといった印象でした。

まとめ

Laravelに置き換えて理解しようとするとアーキテクチャの理解は以前より進んだ気はします。
アーキテクチャの理解は、より良いコード管理につながります。プロジェクトの特性に合わせて、適切なアーキテクチャ要素を選択し、実装することが重要だと思いました。

今回の記事が皆さんのお役に立てましたら嬉しいです。