マイクロサービスアーキテクチャ

5章モノリスの分割

優れたサービスとはどのようなものか、そしてなぜサービスが小さいほどよいのかについて議論してきました。また、システムの設計を進化させられることの重要性についても既に説明しました。しかし、このパターンに従っていない大量のコードベースが既に存在している場合には、どのように対処するのでしょうか。どのようにしてビッグバン型の書き直しをする必要なしにモノリシックアプリケーションを分解するのでしょうか。

モノリス（一枚岩、モノリシックなもの）は時間とともに増大します。新機能やコードを驚くべき速さで取り込みます。すぐに組織にとって恐ろしく巨大な存在になり、手を出したり変更したりするのをためらうようになります。しかし、対策がないわけではありません。思い通りに使える適切なツールがあれば、この怪物を倒すことができます。

5.1　すべては接合部次第

3章では、サービスの凝集性を高め、疎結合にしたいと述べました。モノリスの問題は、大抵はどちらにも反していることです。凝集性をもたらし、一緒に変更する傾向があるものをまとめるのではなく、あらゆる種類の関係のないコードを取り込んで一緒にします。同様に、実際には疎結合も存在しません。コードを変更したい場合には簡単に変更できることもありますが、モノリスの残りの大部分に影響を与えずにその変更をデプロイすることはできず、システム全体をデプロイし直さなければなりません。

Michael Feathersは、その著書『Working Effectively with Legacy Code』（Prentice-Hall、日本語版『レガシーコード改善ガイド』翔泳社、関連記事 http://codezine.jp/article/corner/308）の中で ...