はじめに
お疲れ様です。プログラミング学習中のくろちゃんです。
今回はこれまたエンジニアの友人から聞いたレイヤードアーキテクチャについて聞いたこともなかったためまとめてみます。
知らない言葉ばっかり使ってきやがる友人に感謝しつつまとめていきます！！
アーキテクチャとは
初学者ですのでまずはそもそものアーキテクチャとは何なのかをおさらいしておきます。
アーキテクチャとは「システムの骨組み」や「構造設計」のことです。
アプリケーション全体の構造の考え方ということです。
役割として複数のシステムやアプリケーション、データが連携して動作する際にそれらがどのように組み合わされているのかを明確にするということがあげられます。
そうすることで各構成要素がた互いに干渉せず、効率的に動作するための調整が可能となります。
簡単に役割をあげていきます。
- 責務を分ける
この処理はどこに書くべきかなどの迷いを消します。 - 変更に強くする
アプリケーションを運用していく上で変更は必須事項です。アーキテクチャがあると一部を変更した際に全体に波及しにくくなります。 - 可読性をあげる
良いアーキテクチャは「読めば役割がわかる」構造になります。
フレームワークとの違い
フレームワークは「書き方」を提供しています。
対してアーキテクチャは「考え方」を提供しています。
レイヤードアーキテクチャとは
本題に入ります。
レイヤードアーキテクチャとは、役割ごとに層（レイヤー）に分けて責務を明確にする設計思想のことです。
上で説明したアーキテクチャの具体的な実装パターンの一つがレイヤードアーキテクチャです。
レイヤーとは
上で層（レイヤー）と説明しましたが、少し肉付けすると
同じ責任を持つ処理をまとめた境界
と言えるでしょう。
レイヤー構成
- プレゼンテーション層
・画面
・APIレスポンス
・ユーザーとの入出力 - アプリケーション層
・何をするかを調整
・処理の流れを組み立てる - ドメイン層
・どうあるべきか
・ルール、制約、判断 - インフラ層
・DB
・外部API
・ファイル保存
・メール送信
上の図にあるように依存関係は上の層から下の層のみ許可しています。
逆（下から上）はありません。
「依存関係は上の層から下の層のみ許可する」 とは
依存するとは
あるコードが、別のコードの存在・仕様を前提にして動くことです。
「上の層」「下の層」とは
レイヤードアーキテクチャの層の順番は決まっていません。
ただ一つ、抽象度の高い層から低い層へ依存するという依存方向の一貫性が重要です。
要するに上の層とは「抽象度が高い層」下の層とは「抽象度が低い層」ということになります。
改めて、上の層から下の層のみを許可するとは
抽象度の高い層は、自分より抽象度の低い層のことだけを知っておけばいい
と言い換えられます。
まとめ
レイヤードアーキテクチャとは、処理を責務ごとに層として分離し、
各層が自分の役割に集中するための設計思想です。
重要なのはレイヤーを分けることではなく、分けた後の関係性を固定することです。
抽象度の高い層から低い層への依存関係を忘れないようにしましょう。