ADR-0003: モノレポ構成の採用

ステータス

Accepted - 2024年採用

コンテキスト

Bazbiiは複数のアプリケーション（モバイルアプリ、Webアプリ、バックエンドAPI）と共有パッケージから構成されています。 以下の課題がありました：

• 型定義の共有: Protocol Buffersで定義した型を全アプリケーションで使用したい
• 開発効率: 変更の影響範囲を把握しやすくしたい
• 統合テスト: 全体を一括でテストしたい
• バージョン管理: パッケージ間のバージョン不一致を防ぎたい

決定

モノレポ構成を採用し、以下の構造を実現しました：

bazbii/
├── client-apps/          # クライアントアプリケーション
├── server-apps/           # サーバーアプリケーション
├── server-core/           # ドメインロジック
├── server-platform/       # プラットフォーム実装
└── packages/              # 共有パッケージ
    ├── proto/             # Protocol Buffers定義
    ├── proto-gen-go/      # Go生成コード
    ├── proto-gen-ts/      # TypeScript生成コード
    └── ...

実装方針

1. Go Workspace: Goのモジュール管理に go.work を使用
2. pnpm Workspace: フロントエンドのパッケージ管理に pnpm workspace を使用
3. Protocol Buffers: packages/proto/ で一元管理し、各言語向けにコード生成
4. Makefile: 共通のビルド・テスト・デプロイコマンドを提供

考慮した代替案

代替案1: マルチリポジトリ構成

• メリット:
  • 各リポジトリが独立して管理可能
  • アクセス権限を細かく制御できる
• デメリット:
  • 型定義の共有が複雑（パッケージリリースが必要）
  • 変更の影響範囲を把握しにくい
  • CI/CDの設定が分散する
• 判断: 開発効率と型安全性を優先し、却下

代替案2: ハイブリッド構成（一部のみモノレポ）

• メリット:
  • バックエンドとフロントエンドを分離
• デメリット:
  • Protocol Buffersの共有が複雑
  • 型定義の同期が必要
• 判断: 完全なモノレポの方が管理しやすいと判断

影響

メリット

• ✅ 型定義の一元管理: Protocol Buffers定義を一箇所で管理
• ✅ 変更の影響範囲が明確: 一つの変更がどこに影響するか把握しやすい
• ✅ 統合テストが容易: 全体を一括でテスト可能
• ✅ バージョン不一致の防止: 全パッケージが同じバージョンを使用
• ✅ 開発効率: リポジトリ間の切り替えが不要

デメリット・課題

• ⚠️ リポジトリサイズ: リポジトリが大きくなる
• ⚠️ 権限管理: 全コンポーネントにアクセス権限が必要
• ⚠️ CI/CDの複雑さ: 変更検知のロジックが複雑になる可能性
• ⚠️ ビルド時間: 全体のビルドに時間がかかる可能性

運用上の考慮事項

• 変更検知: CI/CDで変更されたパッケージのみをビルド・テストする仕組み
• 依存関係の管理: Go Workspaceとpnpm Workspaceの両方を適切に管理
• コードレビュー: 影響範囲が広い変更に対するレビュー体制

関連ADR

• ADR-0002: Connect RPCによるHTTP/JSON API提供 - Protocol Buffersの共有

参考

• システム概要
• 依存関係