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というインターフェースを作る部分なので。
コントローラについては、公式ドキュメントに以下のように書いてある「すべてのリクエスト処理ロジックをルートファイルのクロージャとして定義する代わりに、「コントローラ」クラスを使用してこの動作を整理することを推奨します。」
つまり、ルータの延長線上の処理と見ていい。
あと、世間一般的に？ はコントローラにビジネスロジックを書くなという風潮がある。
ビジネスロジック層
そもそもビジネスロジックという単語、設計に関することを調べてると滅茶苦茶出てくる単語なんだけど、定義が滅茶苦茶曖昧で難しい。
よく言われるのは「アプリケーションの核の部分の処理」とか「プレゼンテーション層とアデータアクセス層以外のところ」とか。
私が思ったのは「そのアプリケーションだからこそする処理の部分」という定義。
といってもまだ学び始めなので、とりあえずそんなところがあるんだなぁくらいでいいのではとは思う。
実際に実装をしながら学んでいく部分なんじゃないかな。
ちなみに、ビジネスロジック層にはモデルが該当する。
つまり、アプリケーションのコアとなる部分の処理はコントローラでなく、モデルに書くらしい。
今までモデル部分に記述したこと無いんだけど……
データアクセス層
DBに直接データを要求し、取得・管理するところ。
ここもモデルが該当すると思うのだけど、これはモデルのEloquentがO/RマッパーというSQLとPHPの橋渡しをしてくれているらしい。
つまり、モデルはビジネスロジック層とデータアクセス層のどちらも担当していると言える。
つまり、全部合わせるとこんなイメージ
こうして分けることで責任や役割の分担が明確になり、問題の発生とか拡張性がある程度良くなると。
やっぱやってみないとわかんないね。
おわりに
更にいろんな設計を学ぼうとも思ったんだけど、実践を交えないとちょっとなにやってるのか意識しにくいので、一回MVCと3層のアーキテクチャを使ったWebアプリを作ってみようと思う。
