Chapter 03無料公開

Monolithic Application

okmttdhr
okmttdhr
2020.12.09に更新

UI、ビジネスロジック、Data Accessのコードがひとつのソフトウェアとして管理されている、いわゆるモノリスと呼ばれるアプリケーションパターンです。

Ruby on Railsなどのフレームワークが典型的な例でしょう。その中でも、フロントエンドに関して、モノリスは以下のようなタイプに分けられます。

最小限のJavaScriptを使用

JavaScriptを意図的に最小限にしたアプリケーションです。以下のような特徴を持ちます。

  • ほとんどの画面遷移がサーバーサイドで行われる
  • データの取得や送信は、Ajaxなどの技術を用いず同期的に行われる
  • 画面遷移を用いてUIの切り替えやインタラクションを行うことがある
  • jQueryなどの軽量なDOM操作ライブラリを使用していることがある

部分的にJavaScriptを使用

必要であれば、部分的にJavaScriptを使用したアプリケーションです。ただし、後述するようなモジュールシステムやビルドツールは使いません。以下のような特徴を持ちます。

  • Ajaxなどでモノリス上のAPIを叩き、非同期な通信とインタラクションを提供する
  • 動作が軽快で操作性に優れたUIコンポーネントが存在する
  • 実装によっては重いJS実装がはいり、修正困難なコードが存在する
  • JS単体でのテスト導入がしずらく、E2Eに頼りがちになる。Fragileなテストが生まれることもある

ただし、現在では、ビルドツールがなくてもES Moduleがありますし、ある程度デメリットは解消できるでしょう(ただしIEを除く)。

複雑なフロントエンドが必要ない場合は、薄いJavaScriptでも十分だと筆者は考えます。当たり前ですが、使いやすさとJavaScriptの量は関係ありませんし、下手にアプリケーションの複雑度を上げることは創発にもなり得ます。

ビルドしたJavaScriptを使用

モノリスのプロセスとは別に、JavaScriptをwebpackなどでビルドし、テンプレートエンジンから生成されたDOMに対してマウント、操作を行うようなパターンです。以下のような特徴を持ちます。

  • Ajaxなどでモノリス上のAPIを叩き、非同期な通信とインタラクションを提供する
  • 動作が軽快で操作性に優れたUIコンポーネントが存在する
  • 部分的にClient-Side Renderingを導入でき、一連のある程度複雑な機能も実装できる
  • Virtual DOMやIncremental DOMによる効率的で開発者フレンドリーなDOM操作ができる
  • モジュールシステムにより、コードをカプセル化しやすく、結果的にテストも書きやすい
  • 技術スタックをフロントエンドエンジニアが自由に決められる。故に、バックエンドとフロントエンドのエンジニアの責務がより明確にわかれ始める
  • 開発環境でアプリケーションをすべてつなぎ込んでの動作確認がしにくくなることがある

Modular Monolith

Modular Monolithは、モノリスアプリをドメインで強く境界付けた「モジュール」に分割し、モノリスとマイクロサービスのいいとこ取りをしようというシステムです。ここでいうモジュールは、プログラム的にも参照できないようにしていて、単なるモノレポのような仕組みとは異なることがポイントです。ここでは詳しく述べませんが、気になる方は以下をみるといいかもしれません。

メリット・デメリット

Monolithic Application全体としてのメリットとデメリットを記します。

メリット

  • シンプルなアーキテクチャと実装ができ、特に初期開発においてスピードが早い
  • アプリケーションによっては、技術領域を狭めることで、「ひとり」ないしは数人のエンジニアで開発ができることがある
  • アプリケーションが小さければ、事業ドメインが変化した時、再設計の複雑さが減る
  • 結合テストやシステムテストがしやすい

デメリット

主にコードが肥大化するほどにデメリットが大きくなります。

  • モノリスアプリの技術スタックに引きずられ、他の技術スタックにも制限が発生する時がある
  • コードが追いづらくなり、開発スピードが下がる
  • 少人数だと間に合わず、大人数だと開発効率が下がる
  • 修正の影響範囲が大きくなる
  • 責務が多くなりがちになり、何をやっているかがブラックボックス化する
  • CIなどで時間がかかりがち、Fragileになりがちになる
  • アプリケーションのReliabilityが下がることがある

まとめ

Monolithic Applicationの大きな強みはそのシンプルさです。しかし、それ故に辛みが発生することもわかりました。

また、フロントエンドに関しては、昨今のベストプラクティスに乗り切れないところもあり、徐々に、モノリスアプリから分離したアーキテクチャに進化していることに気付くと思います。プログラム的な辛さがあると、UIとしても実現できるクオリティとコストが釣り合いません。卵か鶏か、というのはありますが、アプリケーションとしてのニーズと、開発者としてのニーズ、それにあわせたWebの進化により、領域ごとの専門性が増し始めたのも、Monolithic Applicationが変化している一因でしょう。