この記事はハワイアンAdvent Calendar 2020 15日目の記事です。今までわたしは感情がない方だったのでVTuberの配信などをみて泣いたりすると「ああ…自分にも感情があったんだ…。」と喜びを感じていたんですが、どうも年を取ると感情の制御ができなくなってくるみたいな話が最近流れてきて、そういうのもあるのかとなりました。ワザップですかこれ。頑固にはなってないと思います。むしろどんどん柔らかくなっているような気がする。

この記事にいきなりやってきた人向けですが、これはある意味連載企画なので、間違えて理解しないように最初から読む事をおすすめします。

珍しくDDD用語も使います。Layered Architectureはアーキテクチャに依存して様々な形となります。POEAA本でのService Layerは、業務表現を閉じ込める事をしました。Onion ArchictectureやHexagonal ArchitectureでのLayerはアプリケーション上の複数のI/O Protocolに対応する為に業務表現をDomain Layerに閉じ込め、その外側のApplication LayerはAnti-Corruption Layerとして機能しました。

BFFやAPIGatewayな文脈ではいわゆるMVC2でいうControllerがService Layerになりました。Fat ControllerやスマートUIパターンが再度評価されるようになってきたのはその為です。BFFやAPI GatewayやMicroservicesな文脈ではわざわざ複数のProtocolをしゃべる必要が後方互換性以外になくなってきたのも大きいです。もちろん必要であればService Layerを続けてもいいんじゃないでしょうか。適切な戦術を選択してくだい。

さらにいえばBFFやAPI Gatewayの開発は現在ではクライアントエンジニアがやっていく事が増えてきました。となってくると、もはやAnti-Corruption Layerはあまり必要とされず、サーバとクライアントが一体となるような設計に近づいてきます。そもそもAnti-Corruptionなんていうぐらいネガティブな言葉選びをされているわけなので、Shared Kernelで済むならそれが良いわけです。Anti-Corruption Layerがなくてはいけなかった、設けざるを得なかった時代が終わりつつあるわけなので、これは良い兆候です。

クライアントアプリケーション設計にもサーバサイドのそのような変化の影響を受け、もはや横方向にLayerを切る時代も終わりつつあり(なんならCommandインスタンスとQueryインスタンスをより直接的にクライアントからサーバに渡したい…)、横に設計を切るというよりは機能単位で縦に設計を切る時代になって来ています。

そのようなアーキテクチャの変化の際に良い設計を保つ上で必要になるのはBusiness Capabilityを軸としたModularityです。結局Modularityに戻ってくる。モバイルアプリ界ではビルドツールに従ってModule化してビルド単位を分ける事ができるので(Xcodeはマルチモジュールを本当に考慮しきれているのか若干疑いがあるけどまあなんか筋肉でやれているのかも)、Web界よりは簡単ですね。Web界はビルドシステムに依存しますが、マルチモジュールな概念がないビルドツールに依存していると難しいです。例えばMonolithからMicroservicesに分割していく際も、そもそもModular Monolithでない状態から始めれば分割の単位を誤る事になるでしょう。DBは共有してサーバアプリケーションを分割するという手もありますが、計画的にやらないと整合性の担保に失敗します。そもそも安易なMicroservices化も止めた方が良いと思います。Microservicesというのは組織構造ありきなので、アプリケーションとして着手する前にやるべき事が沢山あります。

大それたタイトルにしましたが、まあ何にせよ、クライアントサイドでもサーバサイドでもいつの時代も必要なのはLayered ArchitectureではなくModularityで、Layered Architecuteは選択肢の1つでしかなく、戦術として横方向にLayerを切っておけば常に適切なんていう時代は終わりましたよ、というお話でした。