Monorepo VS Monolith

ソフトウェアのアーキテクチャに関する概念
ソフトウェア開発のコード管理における2つの異なるアプローチ

Monorepoとは？

Monorepoは、複数のプロジェクトやコンポーネントを1つのリポジトリで管理する方法です。マイクロサービス単位に分割された資源を維持したまま、共通のコードや依存関係を1つの場所で管理できます。

Googleをはじめ、facebook、Twitterなどでも採用されている手法

▼ Monorepoの一般的な構成の例

my-monorepo/
  ├── packages/
  │   ├── package-1/
  │   │   ├── src/
  │   │   ├── package.json
  │   │   └── ...
  │   ├── package-2/
  │   │   ├── src/
  │   │   ├── package.json
  │   │   └── ...
  │   └── ...
  ├── shared-components/
  │   ├── component-1/
  │   │   ├── src/
  │   │   ├── package.json
  │   │   └── ...
  │   ├── component-2/
  │   │   ├── src/
  │   │   ├── package.json
  │   │   └── ...
  │   └── ...
  ├── package.json
  └── ...

Monorepoの場合、複数のプロジェクトやコンポーネントが1つのリポジトリに収容されるため、ディレクトリ構成はプロジェクトの多様性に合わせて設計される

Monorepoの目指すべき姿は、ソース管理は単一で、デプロイラインは複数

メリット

・プロダクト全体で共通するものの管理に関する問題が解消される
・単一のlint、ビルド、テスト、リリースのプロセス
・モジュールをまたいだ変更がしやすい
・issueを報告する場所が一つ
・開発環境のセットアップが容易
・モジュールをまたいだテストが一緒に実行されるため、複数のモジュールにまたがるバグがより簡単に見つかる
・バージョンアップ対応が楽
　└ 単一リポジトリとなる事で、そのリポジトリ内で一元管理している依存関係をアップデートしてあげれば一瞬で、使用している全サービスへの反映ができる
・ソース管理が単一であるため、コードの重複が少なくなります。共通のコードを効率的に再利用できます。
・プロジェクト全体で共通するものの管理が容易になります。共通のコンポーネントやライブラリを簡単に共有できます。
・ビルド、テスト、デプロイなどのプロセスが単一化されるため、開発者の生産性が向上します。
・モジュールをまたいだ変更がしやすくなり、コード間の連携がスムーズに行えます。

デメリット

・build processが複雑化する可能性がある(大規模なMonorepoではビルドに時間がかかることも)
・ビルドやテストに複数のサーバーを使用する場合がある(プロジェクトによる)
・Monorepoでは、複数のプロジェクトやコンポーネントを1つのリポジトリで管理するため、ビルドプロセスが複雑化することがある。大規模なMonorepoでは、ビルドに時間がかかる可能性がある
・サーバーを複数持たないといけないことがある。ただし、ビルドやテストに複数のサーバーを使用する場合もありますが、この点はプロジェクトの具体的な要件に応じて変わる。

monolithとは？

Monolithは、すべてのコードが1つの大きなアプリケーションとして管理されるソフトウェアアーキテクチャのこと。

▼ Monolithの一般的な構成の例

my-monolith-app/
  ├── src/
  │   ├── components/
  │   ├── pages/
  │   ├── services/
  │   └── ...
  ├── public/
  ├── package.json
  └── ...

すべてのコードが1つの大きなアプリケーションとして管理されるため、主に機能や機能グループによるディレクトリ構成が一般的

メリット

・アプリケーション全体を1つの単位として管理するため、ビルドやデプロイが簡単
・コード間の依存関係を最小限に抑えることができ、ビルドプロセスがシンプルになる
・シンプルなアーキテクチャであるため、新しい開発者が早期にプロジェクトに参加できる可能性が高い

デメリット

・ソースコードが1つのアプリケーションに集中するため、大規模なプロジェクトではコードのメンテナンスが複雑になる可能性がある
・単一のアプリケーションとして管理されるため、コードの重複が増える可能性がある
・アプリケーション全体が影響を受けるため、変更やデプロイが慎重にならなければいけないことがある
・モノリシックなアーキテクチャでは、大規模なプロジェクトではビルドやデプロイが時間のかかることがある

▼ 読みたい資料