3層アーキテクチャを意識して変更に強いシステムを作る

お恥ずかしながら最近3層アーキテクチャを知ったのですが、
これを頭の片隅に置くようにしてから、納得の行くコードが書けるようになりました。

リーダブルなコード・テスタブルなコード・変更に強いコードを書くための方法論は調べたら出てきますが、アーキテクチャやコード設計の部分が一番大事なんだな！と感じました。

というわけで、3層アーキテクチャについて解説していきたいと思います。

システムの処理の流れと3層アーキテクチャ

システムの処理の流れは大体こんな感じです。

1. ユーザーが画面操作してリクエストを送る
2. リクエストを受け取る
3. 処理をする
4. DB（もしくは外部API）とやり取りする
5. 処理をする
6. 処理結果をレスポンスを返す
7. ユーザーに表示する

この処理の流れを3層に分けましょう！っていうのが3層アーキテクチャです。

僕は層ってなんやねん！ って思っていましたが、システムの流れをフェーズごとに区切って役割分担しているイメージです。

3層アーキテクチャそれぞれの役割

3層アーキテクチャはサーバ側の処理を3層に分ける 考え方です。
では先程の処理を3層に分けてみます。

上から下に向かって処理を行い、下まで行ったらまた上まで登ってきます。
こういう風にみると「層」っぽく見えてきますね。

1. ユーザーが画面操作してリクエストを送る
2. ユーザーに表示する

【プレゼンテーション層】
2. リクエストを受け取る
6. 処理結果をレスポンスを返す

【アプリケーション層】
3. 処理をする
5. 処理をする

【データ層】
4. DB（もしくは外部API）とやり取りする

それぞれの層の役割をちゃんと整理してみます。

プレゼンテーション層 ... 画面からリクエストをもらう。画面にレスポンスを返す係
アプリケーション層 ... 処理を行う係
データ層 ... データベースや外部APIとやり取りする係

システムの流れは、プレゼンテーション層→アプリケーション層→データ層→アプリケーション層→プレゼンテーション層と流れていることが分かります。

3層アーキテクチャを意識して変更に強いコードを書こう

冒頭でもお伝えしましたが、なるべく1つのクラスは小さくするとか、単一責任の原則に基づくとか、メソッド分割とかいう技術ももちろん大事ですが、処理の流れと層を意識することでより変更に強いコードが書けると思います。

今自分が書いているコードはどこの層のコードなのか？が分かれば、
「あれ、この処理はこのクラスに書かないほうが良い気がする」ということに気づきやすくなったり、1つのファイルに全ての階層の処理をしてしまっている場合は「ロジックの部分は別のクラスに切り出して、DB通信も別のクラスに切り出そう！」という判断ができるようになります。

終わりに

今回は3層アーキテクチャについて解説してみました。

日々コードを書いていると、どうやったら読みやすくなるだろう？と小手先の技術しか見えなくなってしまうので、よりもっと俯瞰的にコード設計・アーキテクチャの部分も知っておくのが良いなと感じました。

では、また✋