【10日目】Webアプリの設計を知る

投稿日 2023/07/25 最終更新日 2023/07/25

2023年7月22日～2023年7月23日

昨日の続きで、プログラミングにおける設計系を学ぶ。

いわゆるアーキテクチャと言われる部分でもあると思う。

エンジニアがコードを打ち込む時間は全体の10％で、他は勉強とか設計とか要件のすり合わせに使われるってよく言うよね。
今まで私は設計なんてしたことが無いので、心して臨む。

現在の結論

アーキテクチャに正解は無いけど、向き不向きはある。

その上で、アプリケーションの規模や要件に合わせて、”人間が最も楽になる”設計を探さなきゃいけない。この人間には開発者・クライアント・ユーザーが含まれる。

そもそも、時代、人、フレームワークなどの立場によってアーキテクチャの認識、定義が違ったり、定義がふわふわしているものが多い印象。

だから、MVCこそ至高！とか、ドメインモデルこそ最強！とかじゃなく、常に学び続けて現時点での人間が楽になる最善の選択肢を取るのが正解だと思った。

私はそもそも今まで設計を意識してプログラミングを書いたことが無いので、とりあえずトランザクションスクリプトで書いてみたり、MVCで書いてみたりして、メリット・デメリットを肌で感じる必要があるのかなとも思った。

ここからは、一応色々浅く学んだので私の解釈でアウトプットしていく。
重ねてになるけど、全体的に本当に明確な定義がなく、かなり人によって考えが違うのでここでは私の解釈になることをご了承いただいて。

3層のアーキテクチャ

3層に分けて構造を理解しようという概念。3層のアーキテクチャといっても、2種類ある。

1つ目が、Webアプリケーションの3層構造。
2つ目が、アプリケーション内部の3層構造。

Webアプリケーションの3層構造

Webアプリはこんな3層で動いているよね、というもの。

Webサーバー
私の場合はApacheとか
アプリケーションサーバー
私の場合はLaravelとか
※正確にはLaravelの場合、アプリケーションサーバーの部分はApacheが担ってくれているが、役割的にはこう考えて問題ないと思う。
データベースサーバー
私の場合はMySQLとか

図にするとこんな感じ。

アプリケーション内部の3層構造

アプリケーション内部、今回の場合Laravelはこんな感じで動いているよねというもの。

マジで記事や人によって言ってることが違うので、アプリケーション内部の3層構造を理解するというより、この見方からLaravelでは実際何をしているのかを理解することが重要だと思う。

プレゼンテーション層ユーザーインターフェースの部分。
ユーザーやブラウザ（クライアント）とビジネスロジック層の媒介者という感じ。

あくまでも、アプリケーション内部の話なのでクライアント側で動くフロントエンドとはまた別。
ビジネスロジック層メインの処理をする部分。
必要に応じてデータアクセス層に依頼しデータを取得、処理をする。
データアクセス層ビジネスロジック層とDBの媒介者。
DBにアクセスしてデータを取得、整理などをする。

ここではそれぞれ詳しく見ていく。

プレゼンテーション層

Laravelでいう、ルータ、ビュー、コントローラに当たるところだと私は考えている。

ルータは受け取ったリクエストから、然るべき処理に流すところなので当然といえば当然。
ビューはHTMLというインターフェースを作る部分なので。
コントローラについては、公式ドキュメントに以下のように書いてある「すべてのリクエスト処理ロジックをルートファイルのクロージャとして定義する代わりに、「コントローラ」クラスを使用してこの動作を整理することを推奨します。」
つまり、ルータの延長線上の処理と見ていい。
あと、世間一般的に？　はコントローラにビジネスロジックを書くなという風潮がある。