ポリレポからモノレポへ
ポリレポ開発で生じていた問題を解消すべく、バクラクでは2022年9月よりモノレポ開発に挑戦することになった。これまでのように1つのレポジトリで1プロダクトを構成するのではなく、より小さなビジネスドメインにフォーカスしたリソースカットでレポジトリを構成することにしたのだ。
「バックエンドは複数のビジネスドメインを区別した形で含める」「フロントエンドはスモールスタートで小さなプロダクトだけを含める」「インフラはデプロイ設定やTerraformなどのIaCも含める」「サブシステムは機械学習系を含めない」という方針でスタートした。
モジュール管理などの言語が持つエコシステムやCI/CDの記述を容易にするため、ルートディレクトリ配下はGo・Terraform・Web（TypeScript）のように言語ごとに分けることにした。また、アーキテクチャ上の各コンポーネントはディレクトリで表現し、その内部に実装を閉じるようにしたうえで、サービスの一覧性を高めるための「サービス」ディレクトリを設け、その下にサービスA・サービスBといった形でマイクロサービスのディレクトリをつくっている。
開発体制に関しては、モノレポ開発になってからも1プロダクトあたり2〜4人という開発体制は変わらないものの、DevOps責任者を常にアサインするとともに、プロダクト開発のパフォーマンス向上を目的とした「Enabling team」を新たに発足させた。
このようなチーム体制になった背景には、『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（マシュー・スケルトン、マニュエル・パイス著、日本能率協会マネジメントセンター）で紹介されている次の4つの基本的なチームタイプの影響があるという。
- Stream-aligned team：ビジネスドメインにおける一連のフロー（機能の開発・リリース・運用）を担当する。
- Enabling team：Stream-aligned teamとコラボレートしながら障害を取り除き、システムや組織に必要な機能の発見や技術の伝搬を担う。
- Complicated Subsystem team：専門知識を要するシステムの開発や運用に携わる。
- Platform team：チームによるデリバリーを加速するための社内サービス（X-as-a-Service）を提供するように振る舞う。
実際にモノレポでの開発体制にしたことで、「相互のチームが同じコードベースから始められる」「Enabling teamはStream-aligned teamとコラボレートする際のコンテキストスイッチが小さくて済むし、仕組みを伝搬するためのコストも小さくて済む」「Platform teamはサービス提供に必要なコストを小さく抑えられる」といったチーム間の相互作用が生まれた、と中川氏は語る。
全プロダクトのフロントエンドのシングルエントリーポイントとして、アーキテクチャには「API Gateway Pattern」を採用。フロントエンドに向けてはGraphQLを公開し、マイクロサービスのAPIは直接公開しないこととした。また、内部通信には「Protocol Buffers」を採用し、ゲートウェイとマイクロサービス間や、マイクロサービス同士の通信で利用している。これにより、モノレポ内で複数個のプロダクトを構成できるようになった。
GraphQLのゲートウェイレイヤーでは、リソースの集約表現やリレーションの解決など、フロントエンドの表示に関わるリソース解決を一手に引き受けている。その代わり、必要なAPIの呼び出しのみを行い、ユーザー入力から出力を生成するオペレーションのロジックには干渉しない。
その裏にあるマイクロサービスのレイヤーでは、ドメインモデリングを行い、APIを設計する。この過程で、顧客と対話するための重要な構成要素や依存関係を明らかにしていく。
こうしてバクラクシリーズのアーキテクチャは、プロダクト同士で依存関係にあったところから、ビジネスのリソースカットによる連携へと進化したのだ。
