15:30-16:00(30 min)

Modular Monolith Monorepo

• Japanese

イントロ

monorepoの採用が増える中、その真価を発揮させるには単にソースコードを1つのリポジトリに入れるだけでは不十分です。 本セッションでは、スタートアップの開発組織視点から、シンプルさを保ちながらmonorepoのメリットを最大化する「Modular Monolith Monorepo」のアプローチについて、具体的な実装例と意思決定プロセスを交えて紹介します。

想定する対象者

• monorepoで開発する・したい人 - monorepoを管理する・したい人 - ライブラリの依存管理に課題を抱えている人

学べること

実践的なmonorepoのプラクティスと、それに至るまでの意思決定プロセス・コミュニケーションデザインについて

内容

これは現在考えてる発表内容ですが、大まかなイメージです。

• monorepoのメリットとそれを最大化する方法
  • newmoではModular MonolithとMonorepoで開発をしている
  • monorepoのメリット
    • git clone一発で、社内のプロダクトコードが全て網羅できる
    • monorepoにする理由は共通化による管理コストなどを下げる点にある
  • 更に、そのメリットを最大化するためのプラクティスとしてのOne Version Rule
• One Version Rule with pnpmの実践的事例とその課題
  • monorepo内では1つのライブラリは1つのバージョンだけを参照するという仕組み
    • https://tech.newmo.me/entry/one-version-rule-built-on-pnpm-catalog
  • monorepoのインストールがシンプルになりセットアップをシンプルにする
  • プロダクトを一から作成するからこそ取れる選択肢、monorepo管理のアプローチ
  • 将来の拡張性を考えたpnpm catalogsの利用
• Design Docでの議論やTierの考え方などコミュニケーションデザインについて
  • 一方でOne Version Ruleにすることで多種多様なライブラリは利用しにくくなる
  • 実現するためには必要なものはライブラリではなく内部で作る意思決定や、何を使うかという意思決定が重要になる
  • 自由にライブラリを入れる前にDesign Docsを作成し、しっかり議論してから入れるプロセスについて
    • 同じ役割のものは一つだけにして、できるだけやり方を一つにするため
    • 中長期的なスパンを考えて、依存関係の数を管理できるものへと絞るため
    • 入れる前にライブラリの依存度(Tier)を決めて、ライブラリへの依存の仕方の認識を合わせるため
  • 議論したDesign DocsへのリンクをpnpmのCatalogsに入れることで、コードから意思決定の履歴を参照しやすくする工夫など
• 社内向けUIコンポーネントライブラリの例
  • 上記の意思決定プロセスを用いた具体的な事例を紹介
  • パッケージの責務(何をパッケージとして分けるか、の具体)
    • DRYのためにコンポーネントを作らない
    • 共有されるコンポーネントとして作る基準の設計
    • 共有ライブラリとアプリケーション間の責任共有モデル
      • 共有ライブラリ（提供側）とアプリケーション（利用者側）での責務をしっかりと線引したテスト設計

発表の参考情報

• https://j3t.ch/tech/modular-monolith-monorepo/ - https://monorepo.tools/ - https://tech.newmo.me/entry/one-version-rule-built-on-pnpm-catalog