日々の破片

_ 進化的アーキテクチャ、クリーンアーキテクチャ（最初の部分）

同僚が「エンタープライズアーキテクチャーのTo Beってどういうものがあるのか？」とSlackに投げたので、考えた。

モノリス（これだけでは意味を持たないが、良く結合された3層構造以外の選択肢は現在は考えにくい。ただし、プレゼンテーション層としては別にWeb（それがレスポンシブであろうが）にこだわる必要はなく、デスクトップを含めたネイティブアプリケーションであっても良い）はもちろんある。規模が小さければ他に選択の余地はほぼない。

規模が大きければ、SOAが当然の選択肢となる。

ただ、すでにこれらはTo BeというよりもAs Isだ（今が21世紀で良かった）。

マイクロサービスアーキテクチャーはどうだろうか？ このあたりがAs IsとTo Beの分水嶺のように見える。

問題はマイクロサービスアーキテクチャーは理屈の上では正しいと考えられるが、本当にエンタープライズアーキテクチャー足りえるのか？ という点だ。すでにサービスの爆発による失敗事例も話に出てくるようになっている。

マイクロサービスアーキテクチャ(Sam Newman)

もし、そのシステムをゼロから構築するのであれば、マイクロサービスアーキテクチャでシステムを設計するのは楽しそうだが、うんざりしそうでもある。少なくともおれは目がくらくらしてきそうだ。

その一方で、既存のシステムをマイクロサービス化するのが危なっかしいということも容易に想像がつく。

トランザクションの問題だ。

エンタープライズの比較的大きなサービスを分割したために大河トランザクションで流れまくるように構築しなければならなくなったり、ここぞというときにベンダー独自の2フェーズコミットの隘路（2フェーズコミットは理屈と異なり、ネットワークとハードウェアの万全な信頼性を基盤とするので、本当に必要となる不安定な局面では、ミドルウェア自身のバグをつつき出す蓋然性がある。ディスクが本気でやばくなるとRAID5を制御するファームウェアがバグでフリーズしたりするのと同様だ。こういう信じがたい障害が20世紀中に片がついたとは考えにくい）の中で紛失したりするのが想像できる。

クリーンアーキテクチャは素晴らしいが、これは実装アーキテクチャーであって、エンタープライズアーキテクチャーというのとは次元が異なる。

というところまで考えて、島田さんからもらって半分ほど読んで放置していた進化的アーキテクチャを思い出した。で、残りも読んだ。

それが答えだ。

モノリスがベースとして存在し、As Isまたは中期目標のTo Beとしての複数のモノリスを並べたSOAがあるとして、それでも現在のTo Beにはマイクロサービスアーキテクチャがあると考えた場合、これらを共存させつつ、統合させて、「手放す」。「手放す」というのが最終目標だ。

手放すのが目標である以上、サービスは分割されていなければならないし（診断、修理が容易で、かつ容易に交換可能な必要がある）、位置自由でなければならない（位置自由に相当するカタカナ用語が思い出せない。サーバートランスパレント？）し、開発からデプロイ、運用までがパイプラインに並べられている必要がある（唐突に、なぜ今はベルトコンベアという表現をしなくなったのかな？ と疑問が浮かんだ。工業との無意味な類推を招きやすいからか？）

進化的アーキテクチャ ―絶え間ない変化を支える(Neal Ford)

（この文章ではたどり着かなかった）