業務システムとマイクロサービス（２） - 設計者の発言

マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設

[Kouchannel55]

“10チームに分かれてそれぞれ軽快に保守できますよ」「えーっと、保守要員は君を含めて2名なのだが」”

[for-my-internet-demo]

大体しょうがないしか言ってないケースはそれはそれなのでもういいや

[iselegant]

言いたいことはわかるけど、機動力が求められるサービスでモノリスとして扱った時にデグレ確認範囲が広がってビジネスの阻害要因になることも考えられるので、ケースバイケースでは？

[shodai]

共感できる部分はある。ただ、オフラインがオンラインを侵食してる結果ゆえのアーキテクチャとも言える

[w1234567]

逆のパターンの密結合の巨大なスパゲッティモノリスでちょっとした影響調査や改修に1ヶ月とかかかるシステムを沢山みてきてるからなんとも言えないな、業務分析が重要なのは同意だが