重要な点は、モノリスは必ずしも悪いアーキテクチャではなく、単一のテストおよび展開パイプラインなど多くのメリットがある、ということだ。新たな機能を短期間で提供する必要のあるプロジェクトを立ち上げるには、これは非常に有用だ。アーキテクチャの改善に着手すべきなのは、"設計のペイオフライン"を越えた時、すなわち設計の悪さが機能開発を妨げるポイントにおいてのみである。
Shopifyは当初、保守性のよい代替アーキテクチャとしてマイクロサービスを検討していたが、分散システムの複雑性を理由に除外され、代わりに、より保守性のよいモノリスが求められることになった。
結果として、モノリスのような単一で展開可能なユニットを維持しながら、マイクロサービスのようにシステムのモジュール性を高めることが設計目標であるという認識に達したのだ、とWesteinde氏は説明する。これを実現するため、Shopifyでは、モジュラモノリス(modular monolith)パターンを採用した。この方法では、コード間のバウンダリは可能になるが、コードは同じ場所に配置され、同じ場所に展開される。マイグレーションパスは次のようなものだ。
・コードの再編成: 当初のコードは、典型的なRailsアプリケーションのような編成で、トップレベルのパーツには"controllers"など、技術的コンポーネントにちなんだ名前が付けられていた。これを"billing"や"oders"など、ビジネス機能に基づいた編成に変えることで、コードの所在を見つけやすくした。
・依存関係の分離: 各ビジネスコンポーネントを相互に分離し、公開APIを通じて使用できるようにした。各コンポーネントの分離の達成状況を追跡するために、Wedgeという名前の社内ツールが開発された。このツールはコールグラフを作成して、コンポーネント間のコールなど、違反しているコールを見つけ出すことでこれを行う。
・境界の施行: 各コンポーネントが100％分離されると、それらの間には境界が施行される。基本的な考え方は、明示的に依存していないコンポーネントのコードへのアクセスに対して、ランタイムエラーを発生させる、というものだ。このような依存関係を宣言することにより、依存関係グラフで依存関係を視覚化することも可能になる。