Tech Blog

管理画面と顧客向けアプリを「別リポジトリ」に分けた理由と、その判断で得たもの・失ったもの

Architecture Git Design

はじめに

DVDレンタルシステムを作るにあたって、最初に迷ったのは「管理画面と顧客向けアプリを同じリポジトリに入れるか、分けるか」という問題でした。

最終的に別リポジトリにしましたが、その判断は「最初から明確だった」わけではありません。
悩んで、比較して、リスクを受け入れて決めた話です。


最初に考えたこと

同一リポジトリ(モノレポ)の誘惑

最初は「1つのリポジトリにまとめた方が楽じゃないか」と思いました。

  • DB定義(Flyway migration)を共有できる
  • 共通のユーティリティクラスを使い回せる
  • CI/CDを一本化できる

実際、小規模プロジェクトではモノレポで十分です。多くのOSSプロジェクトもそうしています。

しかし、こう考えた

このシステムの将来像を考えたとき、少し違和感がありました。

  • 管理画面はSpring Boot + Thymeleaf(サーバーサイドレンダリング)
  • 顧客向けアプリはSpring Boot + Vue 3(SPA + REST API構成)

技術スタックが根本的に違います。フロントのビルドパイプライン、デプロイ戦略、アクセス制御のレイヤーが違う。
同じリポジトリに入れると、pom.xmlpackage.json の管理が複雑になります。

さらに、将来的にDMMのような総合プラットフォームへ拡張する構想があります。
そこまで視野を広げると、「最初から分けておく」方が自然でした。


判断基準にした3つの問い

問い1:デプロイ単位は同じか?

管理画面と顧客向けアプリは、デプロイのタイミングが必ずしも一致しません。
管理側の機能追加が顧客側の本番環境に影響を与えるのは避けたい。

デプロイ単位が違うなら、リポジトリを分けた方がシンプル

問い2:アクセス権限はどう分けるか?

将来的にチーム開発になったとき、バックオフィス担当者と顧客向けフロント担当者が同じコードベースを触るのは権限管理が面倒です。

リポジトリを分ければ、GitHubのアクセス権限もリポジトリ単位で制御できる

問い3:今後の技術選定が縛られないか?

顧客向けアプリはVue 3ですが、将来Reactに変えたくなるかもしれない。
管理画面はThymeleafですが、将来Next.jsベースにするかもしれない。
同じリポジトリにいると、片方の依存関係が片方を縛ります。

疎結合を保つためにもリポジトリ分割は合理的


実際の構成

dvd-rental-admin/         ← 管理画面(Spring Boot + Thymeleaf + TypeScript)
dvd-rental-customer-app/  ← 顧客向けアプリ(Spring Boot + Vue 3)
dvd-rental-doc/           ← 設計ドキュメント群(共有リソース)

ドキュメントは専用リポジトリ dvd-rental-doc に集約しました。
DBの共有定義(ER図、テーブル仕様)もここに置き、両リポジトリから参照する形にしています。


別リポジトリにして実際に困ったこと

正直に書きます。デメリットもあります。

DBマイグレーションの二重管理

管理画面側のFlywayと顧客向けアプリ側のFlywayは、同じDBに対して動くのに別々に管理しています。
今のところ管理画面側で一元管理し、顧客向けアプリはReadとAPIのみと割り切っています。

ローカル環境の立ち上げが多い

ローカルで両方を動かすには

  • 管理画面: ポート8081
  • 顧客バックエンド: ポート8082
  • フロント(Vite): ポート5173
  • PostgreSQL: ポート15433

4プロセスを起動する必要があります。慣れれば問題ありませんが、最初はやや煩雑です。

コード共有ができない

共通のDTOや定数を使い回したいとき、別リポジトリだと共通ライブラリをMavenリポジトリ経由で管理するか、コピーするかになります。
現在は意図的に両リポジトリを疎結合にしているので「コピー禁止の共通コードを作らない」設計にしています。


得たもの

  • リポジトリごとにブランチ戦略・CI/CDを独立して設計できる
  • 将来の技術変更(フレームワーク乗り換え等)がやりやすい
  • 管理画面と顧客アプリのリリースサイクルを独立させられる
  • GitHubのアクセス権限をリポジトリ単位で制御できる

まとめ

「別リポジトリにすべきか」は、チームの規模・将来の拡張方針・技術スタックの違いによって変わります。
今回は「デプロイ単位が違う」「技術スタックが根本的に違う」「将来の技術選定を縛りたくない」という3点が決め手でした。

モノレポが正解のケースも多くあります。大事なのは「なぜその構成にしたか」を自分の言葉で説明できることだと思います。


このシリーズの記事マップ

dvdrental 管理アプリと対になるエンドユーザー向けDVDレンタルアプリを作っている話 — Vue 3 + Spring Boot の全体構成と記事マップ

気軽にメッセージください

技術相談・ご感想・ご質問があればメッセージをお願いします。