採用理由

LayerX
- noteに詳細
  - monorepoをなぜ採用したか、及び大まかな構成：三井物産デジタルアセットマネジメントでの事例｜Matsumoto Yuki｜note
- もともとマイクロサービスをなるべく適切な粒度で作成・運用していた
  - 共通のインタフェースをどこに置くか、という点で管理が面倒になることが多かった
  - GraphQL、OpenAPI、protobufなど
- １つのリポジトリにインタフェースをまとめることでもっと開発体験が加速するのでは
- 簡単なmonorepoから始めて見ることで想像以上にうまくいった
ソウゾウ
- LayerXと似ている
- protobufの定義といった中央集権的に管理するリポジトリを運用するとマイクロサービスごとのバージョン管理が煩雑に
  - マイクロサービス間の連携時にインターフェースのバージョンが変わったりすると影響範囲を考えながら作業する必要がある
- 結果として開発者がフロントエンド・バックエンド両方の修正を見るようになったなど、副次的にメリットが出てきた
アーキテクチャの柔軟性もメリットに(LayerX)
- monorepoの中で柔軟に変更が可能なので、決まったアーキテクチャに閉じる必要はない
- 最初からきれいなアーキテクチャ境界を決めるのは難しいので、随時変更が可能になっているメリットは大きい
- アーキテクチャ変更時の影響も把握しやすいのもmonorepoのメリットとして大きい

michio

デメリット

ソウゾウ
- リポジトリでかくなる
- 巨大なバイナリファイルを置くとリポジトリ全体が重くなる
  - でかいファイルおかなきゃ良いだけ
- 今の所明確には出てきていない
  - 今後沢山のマイクロサービスを1つのmonorepo内で運用することになった際に何か出てくるのかも
- 周辺のツールチェインがmonorepoに対応していないこともある
  - 普段使い慣れているツールがmonorepoに対応していなくて、やり方を変えなきゃいけないこともある
- 今の所Monorepoにしなければよかったなと思ったことはない
  - 少なくともプロダクト単位であれば、monorepoにするのが良いと思っている
- 将来ものすごくリポジトリが大きくなってきたときへの不安はある
LayerX
- まだ小さいリポジトリなのでまだそんなに起きていない
- ツールチェインをしっかりと作り込める組織じゃないと、monorepoが大きくなってきた際にツライ点が出てくることが予想されている
  - 1つのサービスだけリリースされてくれれば良いのに、全部リリースされるとか

michio

monorepoのスコープ

会社単位で作成するか、プロダクト単位で作成するか？
- LayerXはプロダクトごと
  - 金融ドメインなので、情報の取り扱い的にプロダクトを切り分ける必要が出てくる
  - 会社全体でやるなら色んな苦労ありそう
- ソウゾウもプロダクトごと
  - 今の所、会社単位でmonorepoにすることはアグレッシブな変更だと感じる
  - 会社全体でプロダクトや技術スタックのルールを取りまとめていく必要が出てくる
    - それが取りまとめられるなら会社全体にしても良いかもしれない
    - ソウゾウでは今はプロダクトごとに技術選定などの意思決定は独立しているので、プロダクト粒度で作成するほうが良いと思っている
    - プロダクトごとに性質が異なる場合、プロダクト粒度で作成したほうが柔軟性が上がるのではないか(Layerx)

michio

ビルドシステム

LayerX
- 小さいチームなのでMakefileでやっている
- 言語ごとにディレクトリを作成しているが、そのディレクトリごとにMakefileがある
- 新しく入った人はMakefileを読めばだいたい分かる
- プロジェクトが大きくなったときに、このやり方だけだと難しい
  - 影響範囲だけリリースするなど、凝った作りにする場合
ソウゾウ
- Bazel
- チーム開発ではビルドのリモートキャッシュが威力を発揮している
初期にどれくらいツールチェインの作成に時間をかけるか(ソウゾウ)
- 初期は時間がかかるのはそれはそう
monorepoの重要なポイント(そうぞう)
- 内部のコードの依存関係を検知してビルドする
  - どのサービスが影響を受けて、ビルド・テスト・リリースするか
- これらの検知をやるために全体のツールチェインを決めて進めたことは良かった