Modular Monolithについて調べている
開発の生産性と組織とアーキテクチャ
ソフトウェアエンジニアの開発の生産性は、開発組織やアーキテクチャと無関係ではないと感じることが増えた。以前は、プログラマーとしてあまりにも未熟で具体的な実装に反省点がたくさんあった(もちろん今もある)。最近はそれ以上に、組織とアーキテクチャの不一致により生じる負債の方が致命的だと感じることが多くなった。
組織論としてのmicroservice
「Microservicesは組織論」と言われるようにMicroservicesアーキテクチャの究極的な成果物は新たな組織図である．新たなアーキテクチャに基づく新たなチームの編成，組織の再構成を狙うのが大きな目的である（逆コンウェイの戦略，Inverse Conway Maneuverなどと呼ばれる）．
アーキテクチャにmicroserviceを採用していても、技術や組織が伴っていないと開発のオーバーヘッドが大きくなったり、逆コンウェイの法則でコードが複雑化していくデメリットの方が大きい。思うに、整合性を維持するためにTCCパターンやSagaパターンを採用しなければならなかったり、サービスごとに実装を独立させる分だけコードやインフラの量が増えるというオーバーヘッドは技術の問題で、昔はそれらの知見が不足していたため技術に対する反省が多かった。ある程度知見が溜まってくるにつれて組織的な問題の方が気になり出すというのは自然なことだと思う。
modular monolithは解決策なのか
前述した技術視点での問題は、monolithではあまり発生しない問題だと思うのだけど、組織の問題はmonolithでも起こりうる。事業会社である以上、開発人員の拡大や縮小などは当然起こるからだ。そういった際のアーキテクチャの変更としてmodular monolithを採用するのだろな、と思って各社どのように整理しているのかいくつか資料を調べていた。
ドメインの境界毎にlayered architectureのmoduleに切り出し、module間は公開されたinterfaceを通じた呼び出しのみを許可というのが概ね共通見解。一方で、サービスの定義の単位次第では、microserviceと同じように整合性の問題が生じる場合もあると感じている。そういう場合、DBのトランザクションをmodule間で共有するのか？TCCやSagaパターンを採用するのか？といったことに触れた記事はあまりなかった。
疑問としては上のslideに近いが、実際どのように整理されることが多いのだろうか。調べた範囲での自分の意見だと以下の整理が多くの場合現実的だろうか？と思った。
- TCCやSagaパターンが必要なservice分割はできる限り避ける(それによってコアのtransactionを処理しているサービスがある程度まで大きくなることは許容する)
- 切り出しやすい依存関係(非同期なsubscriberや参照系のデータの組み立てなど)は積極的に切り出していく
- DB Transactionはmodule間では共有しない
最近、modular monolithという言葉はよく聞くけど、具体的な実装レベルの話はあまり出ていなくて残念・・・・。
