Nach fünf Umzügen zwischen Multirepo und Monorepo habe ich gelernt: Es kommt nicht auf die Struktur an, sondern auf die Werkzeuge am Rand. Die Debatte Multirepo vs. Monorepo ist die falsche Frage — die richtige lautet, wie gut deine Tooling-Schicht darunter ist.
Was ein Monorepo zum Funktionieren braucht: Affected-only-Tests, die nur ändern, was wirklich geändert wurde. Remote-Caching, damit die Kollegin nicht nochmal baut, was du gerade gebaut hast. Klare Ownership-Grenzen, damit niemand im fremden Code ändert, was er nicht versteht. Fehlt eines davon, wird das Monorepo zur Single-Point-of-Frustration.
Was wir heute anders machen: Kein Monorepo um des Monorepos willen. Drei zusammengehörige Services teilen ein Repo, der Rest bleibt getrennt. Die Grenze ziehen wir nicht nach technischer Sauberkeit, sondern nach Team-Zugehörigkeit — wer zusammen deployed, zusammen committed, gehört zusammen.