例外を想定したアーキテクチャを考える
アーキテクチャは原理原則とガイドラインを含みますので、原則としてそのルールに従う必要があります。ただ、全てをガチガチに規則を作り、そこからはみ出ないようにしようとすると、どこかでほころびが出てきてしまうことがあります。かと言って、それに対処するように例外対応を行っていくと、もともとのアーキテクチャの思想から外れたシステムが完成します。
きれいなアーキテクチャに限って、それに乗っかることによって何かしらのデメリットが多いケースがあります。メジャーなWeb3層型を矯正するような場合、どのようなアクセスも必ずWebを経由する必要があり、アプリケーションやデータベースへの直接アクセスはできません。データベース直接はまだしも、アプリ直接叩けるサービスとかはほしいですよね。
だいぶ昔の記事なんですけど、いいなと思ってこちらでも紹介です。
DDD(ドメイン駆動設計)は、後先を考えるとたしかにありがたいのですが、重厚長大です。そこでこちらでは、ビジネスロジックの有無で DDD ドメインの有無という操作方法を設計しています。
このように、最初から例外然りの考え方を組み込んで設計しておくと、破綻しにくいアーキテクチャになるということです。結構、きれいにがんばって作り上げたアーキテクチャに完全に従わないとならない結果、特定の領域を同じサービスなので、分離して利用するとかいう謎の仕組みができあがったりします。
例外を受け入れるという緩さももちろん重要ですが、例外となるべきことを想定した上で、アーキテクチャを設計できるように心構えとして持っておきたいところです。
いいなと思ったら応援しよう！
