【Javaのお勉強】レイヤードアーキテクチャについてお勉強する

直接的に「Javaのお勉強」ではないんですが、でもあの謎の@Controllerとか@Serviceとかをちゃんと理解する為には避けては通れぬ道。
なお、まだあの謎の@がどの技術に依存して存在しているのかはいまいちよく分かっていません。SpringBootなの？違うのもあるよね？

【参考サイト】

レイヤードアーキテクチャの視点 - Qiita

とりあえず今回はざっくり概要を押さえていきます。

ざっくり概要

※Canvaで画像作ると楽で綺麗で早くて良いですね。

レイヤードアーキテクチャとは

和訳すると「（システムを）層状に構築する方法論」ってところでしょうか。横文字難しい。

システムを作るときには色々な機能が必要になりますが、その機能を、種類別に分類して、分類した機能を層状に構築することで、指示系統（依存関係）をスッキリさせ、見通しをよくして、変更に強いシステムを作りましょう、という考え方。

レイヤードアーキテクチャに従うと、機能は基本的に4種類の層に分けられます。

・UI層（Presentation層）→アプリケーションの表示に関わることを取り扱う。入出力内容のフォーマットとか、表示テンプレートの指定とか。

・Application層→UI層の指示に応じて、必要な処理を行うために、必要なDomainを組み合わせて呼んでくる。（domainのコーディネート）

・Domain層→ビジネスルール・仕様を取り扱う。「’税込価格をくれ’と言われたら価格×1.1を返す」とかの、実際の計算・処理を行う。

・Infrastructure層→データの永続化に関することを扱う。（永続化ってなんじゃってなるけど、要するにデータベースとかに保存して消えないようにすること。メモリ上だけで取り扱ってると消えちゃうからね）逆にデータベースから情報を取ってくる時もここを介す。

※この辺の細かいことは正直参考サイト読んでくれって気持ちですが、学習記録なので、学習したことを自分の言葉でまとめ直す為に書いています。

依存関係を一方通行にする

つまり、下の層から上の層のメソッドを呼ばない。

DomainからDomainを呼ぶ、みたいなことも原則的にはしない。（「本棚」domainが「本」domainを呼ぶ、みたいな使い方はあり得る）

間をすっ飛ばして命令しない

UI層は必ずApplication層を呼ぶ。突然Domainを直接操作したりしない。

UIが営業さん、Applicationが事務さん、Domainが工場だとすると、営業さんが直接工場に「ちょこちょこっとこれだけ作ってよ！簡単だからさ！」みたいな依頼をすると、事務さんがその発注に気づけず、とんだ計算違いが起きて「ちょっとその案件聞いてないんですけど？？？」って営業さんにむっちゃ怒る、みたいな感じ（と理解した）。

どうしてこんな面倒くさい実装にするのか

UIに「1000円の税込価格は？」って入力されたら、そのまま「1100円です」って答える

これだけで済むはずが、レイヤードアーキテクチャを採用すると、

UIが「1000円の税込価格は？」ってApplicationに聞く
ApplicationがDomainに「1000円の税込価格は？」って聞く
domainが「1100」って答える
Applicationがdomainから答えを受け取って「1100」って答える
UIがApplicationから答えを受け取って「1,100円です」って表示する

っていう手順が必要になる。正直面倒。

だけど、実際にアプリケーション作る時にはもっとずっとくっそ複雑な処理の連続になるし、運用に合わせて必要な処理もどんどん変わる。

例えば、ある日消費税が撤廃されたとする。（仮に消費税が撤廃されたらこのツール要らなくなるけど、それは今は考えない）
仮に1つの関数が、これら全部の処理を担当していたとしたら、「1.1」になっているところを一つずつ探して「1.0」に書き換えないといけない。

ある日突然日本の通貨が￥じゃなくて、なんか、♄とかになってしまったとする。（なおこの場合￥1＝♄1とする）
やっぱり、「￥」が書いてある所を一つずつ以下略。

これをちゃんとレイヤードアーキテクチャを使って設計しておけば、

消費税が撤廃されたら、消費税の実際の計算をしているのはdomain層だから、domain層を書き換えればOK！
通貨単位が変わっちゃっても、表示だけ変えれば良いんだからUI層だけ書き換えればOK！

と、変更箇所がわかりやすい。他の人が作ったプログラムを急に引き継いだとしても、5年前の自分が実装したコードを弄らなくちゃいけなくなっても、目星がつけやすいし、他の部分への影響も想像しやすい。

と言うわけで、レイヤードアーキテクチャに則ってアプリケーションを設計するといいよ、というお話でした。本日はここまで。