1つのものに大量に依存することを避ける

Business Logicは根幹なので、やろうと思えば全てをここに依存するように設計することもできる

しかし、レイヤー構造にすることで、その修正による影響の波及を軽減できる

つまり、ビジネスロジックが多くの箇所から依存されないようになる

Layered Architectureの効能は、「依存の方向を1方向にする」だけではない

それだけならレイヤーである必然性がない

WIP

例えばその関数を意味的にグルーピングしたwrapperを作るとか

また、wrapperを作った場合抽象度の上下関係を明示する必要がある

何かしらでルールを明示しないと、利用者はどちらに依存すべきなのかの判断がつかない

まさにこの図の感じ

https://gyazo.com/b4bd75a8e23e66df2edc8469672a57d8

『Clean Architecture』.icon 24章

設計者の意図としては、Client→ServiceBoundary→ServiceImplという上下関係を規定しているつもりでも、

Clientは、ServiceBoundaryを参照すべきか、ServiceImplを参照すべきかの判断がつかない

この例ではInterfaceとImplなので自明にわかりそうに見えるが、それぐらいの自明さがないと上下関係がわからない

しかし、ただlayerを作れば良い、というわけでもないと思う

汎用的な関数を、依存を避けるためだけにwrapperを用意するのもおかしい

同じ意味なのであれば、同じものを参照したほうが正しい

無意味なInterfaceと同じような問題が起きる

その境界が、どういう修正に対して堅牢になっているのかを理解した上でそうしないといけない