Layered ArchitectureのLayer構造の意味
Layered Architectureのレイヤー構造の意味
自分より変更されにくいものに依存するためのデザインパターンのようなもの
外側は変更されやすく、内側は変更されにくい
外側が変更された時、内側はそれを気にする必要はないような依存関係を目指している
逆に内側が変更されると、外側がみんな影響を食らう
これは仕方がない。
変更されやすさに順序を付けてそれをレイヤーにすることで、全体としての変更されやすさを抑えていている
例えばこれはThe Clean Architectureのレイヤー構造
最も外側が、最も変更されやすい
外部のサービスと結びついているから
例えばViewとかは顕著
ブラウザが異なったら、見え方も異なる
OSが異なったら、見え方も異なる
細かい見た目の変更によっても修正される
みたいなことがしょっちゅう起こってる
壊れやすい、不安定
IOと関わるものが最も不安定になる
だから、よくあるLayered Architectureは外側にIOが配置されている
最も中心が、最も変更されづらい
business logicがめちゃくちゃ変わることはそんなにない
もちろん機能追加などがあればそこにmethodを加えることもあるが、既存のものにはあまり触れない
これはオープン・クローズドの原則 (OCP)を考慮しようというのもある
business logicはサービスの根幹なので、サービスとして最も大事な部分
なので、この世界では、ここだけに集中したい
周囲の世界であるOSとかブラウザとか外部サーバー等のごたごたを考えたくない
仕様を満たした型のみを受け付けるプログラムを書いて理想世界を築く
抽象化して見ると、内側こそがアプリケーションそのものであり、
より外側のものは全て「それのプラグイン」と考えることができる
ビジネスロジックは替えが効かないが、RDBMSやViewは何にでも変更可能
Layered Architectureは、いくつかの問題を総合的に解決する方法と捉えられる
以下の課題は個別に問題視すれば別にレイヤードにはならないはず
これらを総合的に解決するアーキテクチャとして、Layeredにするのが適している
凝集させる
たいていレイヤーごとにファイルを分けることは前提に話が進むが、もう少し考える必要があるように思う
レイヤー構造になっていようと、同じファイルに書くこともできるし、各機能を関数で書いていれば明示的なレイヤーは消える
レイヤーを対象とした/mrsekut-b/モデリングの最初の段階という問題もある
一般的なWebアプリケーションならCAとかに倣っておけばだいたい耐えるんだろうけど、ちょっと変わったことをやるプロダクトなら、「どういうふうにレイヤーを分けるか」というめちゃくちゃ重要な問題が出てくる
レイヤードアーキテクチャはOSとかでもあるし
Entity部の設計がおかしいと、プロダクト全体が辛くなる
と、思ったが、
「依存を集中することを避ける」思想ならば、そうはならない？とかある？