Wie sieht die Standard-Verzeichnisstruktur eines Next.js-Projekts aus?

Eine Standard-Verzeichnisstruktur für ein Next.js-Projekt ist kein einzelner, für jedes Team gleichermaßen richtiger Ordnerbaum. Sie bedeutet vielmehr, definierten Konventionen für Routing-Dateien zu folgen, die das Framework interpretieren muss, und den übrigen Code entsprechend der Art des Projekts abzulegen. Für ein neues Projekt ist ein leicht verständlicher Ansatz meist, src/app zum Zentrum für URLs und Seiteneinstiegspunkte zu machen, an mehreren Stellen verwendete UI in components auszulagern, bei Bedarf funktionsspezifische Logik in features unterzubringen und gemeinsam genutzte Hilfsfunktionen in lib zu halten. Der App Router ist im aktuellen Next.js der primäre Routing-Ansatz, während der Pages Router weiterhin unterstützt wird. nextjs.org↗nextjs.org↗

Beim erstmaligen Definieren einer Struktur geht es nicht darum, möglichst viele Ordner anzulegen. Unterscheiden Sie zunächst, welche Dateien URLs erzeugen, welche Layouts, Fehlerseiten und APIs behandeln und welcher Code nur innerhalb eines bestimmten Bildschirms verwendet wird. Dieser Artikel erläutert anhand dieser Unterscheidungen eine wartbare, auf den App Router ausgerichtete Struktur.

Warum gibt es in Next.js keine „einzige Standardstruktur“?

Next.js stellt Konventionen bereit, um Routen aus Dateien und Ordnern zu erstellen, schreibt jedoch nicht exakt vor, in welchen Ordnern jede Komponente und jede Geschäftslogik liegen muss. Besonders im App Router repräsentieren Ordner URL-Segmente, und spezielle Dateien wie page.tsx und route.ts erstellen tatsächliche öffentliche Einstiegspunkte. Normale Dateien innerhalb einer Route werden dagegen standardmäßig nicht zu externen Routen. nextjs.org↗

Aufgrund dieser Eigenschaft können sich Strukturen sogar zwischen Next.js-Anwendungen unterscheiden. Eine kleine Marketing-Website benötigt möglicherweise nur app und einige gemeinsam genutzte Komponenten. In einem Dienst mit mehreren Bereichen wie Dashboards, Bestellungen und Konten erleichtert die Trennung funktionsspezifischen Codes von gemeinsam genutztem Code hingegen das Verständnis des Änderungsumfangs. Das ist keine von Next.js verlangte absolute Regel, sondern ein Ansatz zur Codeorganisation, den ein Team auf die Routing-Konventionen aufsetzt.

Es ist daher weniger verwirrend, „Standard“ in den folgenden zwei Ebenen zu betrachten.

Eine willkürliche Änderung der ersten Ebene kann das Routing oder das Verhalten spezieller UI verändern. Die zweite Ebene kann je nach Größe und Komplexität der Domäne weggelassen oder kombiniert werden. Beispielsweise ist eine Struktur ohne features möglich, und in einem kleinen Projekt muss nicht jeder Codebestandteil übermäßig fein segmentiert werden.

Warum sollten neue Projekte um den App Router herum gestaltet werden?

Der App Router ist ein Ansatz zum Erstellen von Seiten und Layouts auf Grundlage des Verzeichnisses app. Die offizielle Dokumentation empfiehlt den Wechsel vom Pages Router zum App Router, um die neuesten React-Funktionen nutzen zu können; der Pages Router selbst bleibt jedoch unterstützt. Daher sollten Sie die pages-Konventionen beim Warten oder Erlernen einer bestehenden Projektstruktur verstehen, aber es ist naheliegend, den App Router beim Entwurf einer neuen Struktur als Standardkandidaten zu behandeln. nextjs.org↗

Der Kern des App Routers besteht darin, die URL-Hierarchie mit der Dateihierarchie zu verbinden. Beispielsweise wird app/dashboard/page.tsx zum Einstiegspunkt für die Seite /dashboard, während ein darunter liegendes app/dashboard/layout.tsx ein Layout für Dashboard-Unterrouten bereitstellen kann. Das Stamm-app/layout.tsx ist das Root-Layout, das alle Routen umschließt. nextjs.org↗

Dieser Ansatz eignet sich gut dafür, Code auf Bildschirmebene nahe beieinander zu halten. Tabs, Tabellen und Filter-UI, die nur für /dashboard benötigt werden, können unter app/dashboard liegen, während Buttons oder Eingabefelder, die auf mehreren Bildschirmen wiederverwendet werden, in einen externen gemeinsamen Ordner verschoben werden können. Das entscheidende Kriterium ist nicht „mit welcher Technologie wurde diese Datei geschrieben?“, sondern „in welchem Umfang wird sie wiederverwendet?“

Die Verwendung des App Routers bedeutet jedoch nicht, dass aller Code in app liegen muss. Sie können app als Grenze behandeln, die URLs und spezielle Dateien gut lesbar macht, und gemeinsamen Code oder komplexe Feature-Implementierungen bei Bedarf in andere Ordner auslagern. Diese Trennung wird nicht automatisch von Next.js vorgenommen; sie ist eine Strukturkonvention, die das Team einheitlich festlegt.

Wann sollten Sie einen src-Ordner verwenden, und was bleibt im Stammverzeichnis?

src ist optional. Wenn Sie ihn verwenden, können Sie app und den Anwendungscode unter src bündeln und Konfigurationsdateien dadurch visuell vom Laufzeitcode trennen. Dagegen gehören public, package.json, next.config.js, tsconfig.json und .env.*-Dateien in das Projektstammverzeichnis. nextjs.org↗

Das Folgende ist ein leicht verständliches Beispiel für die Verwendung des App Routers zusammen mit src.

my-app/
├─ public/
│  ├─ images/
│  └─ fonts/
├─ src/
│  ├─ app/
│  │  ├─ layout.tsx
│  │  ├─ page.tsx
│  │  ├─ globals.css
│  │  ├─ (marketing)/
│  │  │  └─ about/
│  │  │     └─ page.tsx
│  │  ├─ dashboard/
│  │  │  ├─ layout.tsx
│  │  │  ├─ page.tsx
│  │  │  ├─ loading.tsx
│  │  │  ├─ error.tsx
│  │  │  └─ _components/
│  │  └─ api/
│  │     └─ users/
│  │        └─ route.ts
│  ├─ components/
│  ├─ features/
│  ├─ lib/
│  ├─ hooks/
│  └─ types/
├─ .env.local
├─ next.config.js
├─ package.json
└─ tsconfig.json

In diesem Beispiel ist src nur eine Grenze für Anwendungscode, kein erforderlicher Mechanismus, der das Verhalten verändert. Wenn ein bestehendes Projekt bereits app im Stammverzeichnis hat, kann es besser sein, der etablierten Konvention konsequent zu folgen, statt die Hinzufügung von src zu erzwingen. Insbesondere wenn Verzeichnisse namens app oder pages sowohl im Stammverzeichnis als auch in src vorhanden sind, hat das Stammverzeichnis Vorrang. Deshalb ist es wichtig, während einer Migration keine doppelten Strukturen über einen längeren Zeitraum bestehen zu lassen. nextjs.org↗

Das praktische Kriterium für die Wahl von src ist einfach. Es ist sinnvoll, wenn Sie Konfigurationsdateien klar vom Produktcode trennen möchten oder mit einer wachsenden Anzahl von Quelldateien rechnen. Umgekehrt besteht keine Notwendigkeit, es in einem Lernprojekt oder einem sehr kleinen Projekt zu übernehmen, dessen Stammstruktur bereits übersichtlich ist.

Welche Dateien im app-Ordner erzeugen tatsächliche Routen?

Im App Router repräsentieren Ordner Teile einer URL, also Segmente. Allein das Erstellen eines Ordners app/dashboard macht /dashboard jedoch nicht zu einer öffentlichen Seite. Enthält dieser Ordner page.tsx, wird er zu einer Route mit Seiten-UI; enthält er route.ts, wird er zu einem API-Endpunkt auf Grundlage eines Route Handlers. nextjs.org↗

Betrachten Sie beispielsweise das folgende Layout.

src/app/
├─ page.tsx
├─ about/
│  └─ page.tsx
├─ dashboard/
│  ├─ page.tsx
│  └─ reports/
│     └─ page.tsx
└─ api/
   └─ users/
      └─ route.ts

In diesem Fall entspricht page.tsx jeweils /, /about, /dashboard und /dashboard/reports. api/users/route.ts ist keine UI-Seite, sondern definiert einen API-Endpunkt. Sobald Sie verstehen, dass page.tsx und route.ts als öffentliche Einstiegspunkte einer Route dienen, wird klar, warum andere Dateien im selben Ordner liegen können. nextjs.org↗

Diese Eigenschaft lässt sich als Colocation betrachten. Colocation ist ein Organisationsansatz, bei dem zusammengehöriger Code nahe beieinander bleibt. Beispielsweise können Tabellenkomponenten, die nur in dashboard verwendet werden, bildschirmspezifische Formatierungsfunktionen und Code zur Transformation von Testdaten nahe bei app/dashboard abgelegt werden. Das bedeutet nicht, dass gemeinsame Ordner niemals verwendet werden sollten. Sie müssen lediglich Code, der von anderen Routen wiederverwendet wird, in Ordner mit einem breiteren Geltungsbereich verschieben.

Wie sollten layout-, loading- und error-Dateien getrennt werden?

layout.tsx behandelt die gemeinsam genutzte UI-Hülle. Das Root-app/layout.tsx umschließt alle Routen, während ein layout.tsx in einem untergeordneten Ordner verschachtelt auf dessen Unterrouten angewendet wird. Wenn beispielsweise die Dashboard-Navigation von /dashboard und /dashboard/reports gemeinsam verwendet wird, kann sie in app/dashboard/layout.tsx liegen. nextjs.org↗

page.tsx ist die Seiten-UI, die unter einem bestimmten Pfad angezeigt wird. Wenn ein Layout die wiederkehrende äußere Struktur darstellt, entspricht eine Seite eher dem pfadspezifischen Inhalt, der sich darin ändert. Durch die Trennung müssen Sie gemeinsame Navigation oder Rahmen nicht auf jeder Seite wiederholen.

Der App Router stellt außerdem reservierte Dateien für zustandsspezifische UI bereit. loading.tsx wird für Lade-UI verwendet, error.tsx für Fehler-UI und not-found.tsx für Nicht-gefunden-UI. Anders als gewöhnliche Komponentendateien interpretiert Next.js diese Dateien für bestimmte Rollen; sie sollten daher mit Blick auf Rolle und Geltungsbereich platziert werden. nextjs.org↗

Wenn Sie beispielsweise einen separaten Bildschirm anzeigen möchten, während Daten unter /dashboard vorbereitet werden, können Sie app/dashboard/loading.tsx in Betracht ziehen. Benötigen Sie eine Oberfläche für die Fehlerbehandlung in diesem Bereich, können Sie app/dashboard/error.tsx erwägen. Es ist nicht nötig, diese Dateien mechanisch in jeden Ordner einzufügen. Die Entscheidung danach, ob jede Route tatsächlich separate UI für Warte-, Fehler- oder Nicht-gefunden-Zustände benötigt, hält die Struktur kompakt.

Wie werden dynamische Routen und API-Routen in Ordnernamen dargestellt?

Verwenden Sie die Klammerschreibweise, wenn ein Teil einer Route nicht vorab feststeht. [slug] bedeutet ein dynamisches Segment, [...slug] bedeutet alle folgenden Untersegmente und [[...slug]] bedeutet eine optionale Form, bei der diese Untersegmente fehlen können. nextjs.org↗

Beispielsweise kann eine Seite mit einer variablen Beitragskennung folgendermaßen strukturiert werden.

src/app/posts/
└─ [slug]/
   └─ page.tsx

In dieser Struktur ist [slug] kein fester Ordnername, sondern ein Platzhalter, der den veränderlichen Teil der URL entgegennimmt. Wenn dagegen mehrere Ebenen einer Route durch eine einzelne Konvention behandelt werden müssen, sollten Sie [...slug] oder [[...slug]] in Betracht ziehen. Welche Schreibweise Sie wählen, hängt davon ab, ob mindestens ein Unterpfad vorhanden sein muss und ob auch der Fall ohne Pfad vom selben Bildschirm behandelt werden soll. nextjs.org↗

Beim Erstellen von APIs ist route.ts der Einstiegspunkt für einen Route Handler. Sie können die URL-Struktur daher mit Ordnern wie app/api/users/route.ts darstellen und route.ts am Ende platzieren. Sowohl bei Seiten als auch bei APIs ermöglicht die Ordnerhierarchie, den ungefähren Pfad abzuleiten. Dedizierte Implementierungsdateien sollten jedoch sinnvoll getrennt werden, damit UI- und serverseitiger Verarbeitungscode nicht im selben Bereich zu stark vermischt und zu umfangreich werden. nextjs.org↗

Warum werden Routengruppen und private Ordner benötigt?

Ein in Klammern gesetzter Ordner wie (marketing) ist eine Routengruppe. Er ist eine logische Gruppierung, die nicht in der URL enthalten ist. Sie können beispielsweise marketingorientierte Seiten wie Unternehmensinformationen und Preise gruppieren und Bildschirme zur Produktnutzung in einer getrennten Struktur verwalten. app/(marketing)/about/page.tsx wird zur Route /about, ohne dass der Gruppenname erscheint. nextjs.org↗

Routengruppen sind nützlich, wenn Sie Layout-Grenzen oder Code-Verantwortlichkeiten sichtbar machen möchten, ohne die URL zu ändern. Da der Gruppenname jedoch nicht in der URL erscheint, entsteht ein Konflikt, wenn getrennte Gruppen letztlich dieselbe URL erstellen. Außerdem kann eine Konfiguration, die zwischen mehreren Root-Layouts wechselt, ein vollständiges Laden der Seite verursachen. Root-Layouts sollten daher nicht leichtfertig nur aufgeteilt werden, damit Ordner aufgeräumt aussehen. nextjs.org↗

Ordner, die mit einem Unterstrich beginnen, etwa _components und _lib, sind private Ordner und vom Routing ausgeschlossen. Im App Router werden gewöhnliche Dateien standardmäßig ohnehin nicht zu Routen, daher ist ein Unterstrich nicht zwingend erforderlich. Er kann dennoch nützlich sein, wenn Sie die Grenze zwischen speziellen Routing-Dateien und interner Implementierung sichtbar markieren oder Verwechslungen mit reservierten Dateinamen vermeiden möchten. nextjs.org↗

Beispielsweise vermittelt app/dashboard/_components/summary-card.tsx, dass es sich um Dashboard-spezifische UI handelt. Wird diese Komponente jedoch wiederholt in anderen Features verwendet, ist es naheliegender, sie aus dem Unterstrich-Ordner in gemeinsame components oder eine geeignete Feature-Grenze zu verschieben. Denken Sie daran, dass ein Ordnerpräfix kein Zugriffskontrollmechanismus ist; es ist eine Schreibweise, die die Rolle des Codes vermittelt.

Wie sollten Sie components, features, lib, hooks und types unterscheiden?

Diese Ordner sind optionale Organisationsentscheidungen und keine reservierten Konventionen des App Routers. Deshalb sind die vom Team vereinbarten Verantwortungsgrenzen wichtiger als die Namen selbst. Die folgenden Unterscheidungen sind ein verbreiteter Ausgangspunkt.

components kann nicht nur generische Buttons, sondern auch zusammengesetzte UI enthalten, die von mehreren Features geteilt wird. Wenn jedoch jedes UI-Element von Beginn an zu einer global geteilten Komponente gemacht wird, können Implementierungen abstrahiert werden, die tatsächlich nur von einem Bildschirm benötigt werden. Ein anderer Ansatz besteht darin, sie zunächst nahe bei der Route zu halten und sie erst zu verschieben, wenn sie stabil an zwei oder mehr Stellen verwendet werden und eine klare gemeinsame Schnittstelle haben.

features ist besonders gut lesbar, wenn eine domänenorientierte Struktur erforderlich ist. Wenn beispielsweise Bestellungen und Konten jeweils unabhängige Bildschirme, UI und Datenverarbeitungscode besitzen, können Sie sie als features/orders und features/account gruppieren. Umgekehrt kann das Anlegen zu vieler Feature-Ordner auf einer einfachen Website dazu führen, dass Personen nur zum Auffinden von Dateien durch viele Ordner navigieren müssen. Es ist besser, sie erst einzuführen, wenn Feature-Grenzen mit tatsächlichen Produktkonzepten übereinstimmen.

lib ist ein möglicher Speicherort für grundlegenden Nicht-UI-Code wie gemeinsame Hilfsfunktionen oder Server-Clients. Wenn sich jedoch jede Funktionsdatei in lib ansammelt, kann daraus ein großer, schwer verständlicher Ablageort werden. Eine praktische Regel besteht darin, Werkzeuge, die nur von einem Feature verwendet werden, nahe bei diesem Feature oder dieser Route zu halten und nur an mehreren Stellen genutzten Code nach lib zu verschieben.

Warum gehören public und Umgebungsvariablendateien in das Projektstammverzeichnis?

public ist der Ordner im Projektstamm für statische Dateien. Dort abgelegte Dateien werden über den Root-Pfad bereitgestellt; beispielsweise wird public/profile.png als /profile.png referenziert. Dadurch gibt es einen zentralen Ort für statisch ausgelieferte Dateien wie Bilder und Schriftarten. nextjs.org↗

Auch bei Verwendung von src sollten Sie nicht davon ausgehen, dass public nach src/public verschoben wird. public bleibt im Projektstamm, und auch package.json, next.config.js, tsconfig.json und .env.* werden vom Stamm aus verwaltet. Insbesondere weil lokale Umgebungsvariablendateien wie .env.local Geheimnisse enthalten können, ist es wichtig, eine Betriebsregel festzulegen, nach der sie nicht in die Versionsverwaltung aufgenommen werden. nextjs.org↗

Die Unterscheidung der Rollen statischer Assets und Anwendungscode macht Pfade leichter verständlich. Dateien in src/app sind Code, der Bildschirme oder Routing erstellt, während Dateien in public statische Assets sind, die über URLs referenziert werden. Selbst wenn dasselbe Bild auf einem Bildschirm verwendet wird, müssen Sie seine Auslieferungsart und seinen Referenzpfad je nach Ablageort unterschiedlich verstehen.

Worin unterscheidet sich dies von der Struktur des Pages Routers?

Der Pages Router behandelt Dateien im Verzeichnis pages als Routen. Beispielsweise entspricht pages/index.tsx / und pages/about.tsx entspricht /about. Reservierte Dateikonventionen weisen außerdem _app, _document, 404, 500 und anderen spezielle Rollen zu. nextjs.org↗

Es ist leicht, Fehler zu machen, wenn Sie App Router und Pages Router als Ansätze betrachten, die sich nur im Ordnernamen unterscheiden. Im App Router teilen spezielle Dateien wie page.tsx, layout.tsx und route.ts unterhalb von Ordnersegmenten die Verantwortlichkeiten auf, während gewöhnliche Dateien standardmäßig keine Routen sind. Im Pages Router sind Dateien innerhalb von pages direkter mit Routen verbunden. nextjs.org↗nextjs.org↗

Wenn Sie mit einem bestehenden Pages-Router-Projekt arbeiten, sollten Sie dessen aktuelle pages-basierte Konventionen respektieren. Wenn Sie dagegen ein neues Projekt starten, reduziert eine auf dem App Router basierende Beispielstruktur, der Sie Organisationsordner nur bei tatsächlichem Bedarf hinzufügen, den Aufwand. Es ist wichtig, die Konventionen der beiden Router nicht innerhalb desselben Verzeichnisdesigns zu vermischen.

Welche Kriterien sollten Sie zur Wahl einer Struktur für ein reales Projekt verwenden?

Beginnen Sie zunächst mit der URL-Struktur. Listen Sie die wichtigsten Pfade auf, auf die Benutzer zugreifen, und legen Sie dann fest, welche gemeinsamen Layouts jeder Pfad verwendet. Stellen Sie das Ergebnis durch Ordner in app sowie die Platzierung von page.tsx und layout.tsx dar. Verwenden Sie Routengruppen, wenn es einen klaren Grund gibt, Bildschirmbereiche oder Layouts ohne Änderung der URLs zu trennen. nextjs.org↗nextjs.org↗

Bewerten Sie zweitens den Umfang der Wiederverwendung. Halten Sie Code, der nur von einer Route verwendet wird, nahe bei dieser Route. UI, die von mehreren Routen verwendet wird, kann in einen breiteren Bereich wie components verschoben werden, und Hilfsfunktionen, die mehrere Features verwenden, können nach lib wandern. Anstatt alles von Beginn an zu verallgemeinern, hilft das Trennen von Code, sobald tatsächliche Wiederverwendungs- und Änderungsmuster entstehen, unnötige Abstraktion zu reduzieren.

Berücksichtigen Sie drittens die Unabhängigkeit von Features. Wenn Features mit klaren Verantwortungsbereichen und Begrifflichkeiten – etwa Konten, Administration oder Bestellungen – größer werden, können Domänengrenzen wie features sinnvoll sein. Bei wenigen Bildschirmen und schwachen Unterscheidungen zwischen Features kann dagegen Colocation in app zusammen mit einer kleinen Anzahl gemeinsamer Ordner ausreichen.

Prüfen Sie viertens die Auffindungskosten für das Team. Wenn ein neues Teammitglied Code für eine bestimmte URL sucht, sollte es dem app-Pfad folgen und die Seite sowie die zugehörige Implementierung finden können. Auch Namen und Speicherorte gemeinsamer Buttons oder Hilfsfunktionen sollten vorhersehbar sein. Eine gute Struktur entsteht eher aus dieser Vorhersehbarkeit als aus angesagten Ordnernamen.

Welche Missverständnisse und strukturellen Fallstricke sollten Sie vermeiden?

Das erste Missverständnis lautet: „Das Erstellen eines Ordners erzeugt sofort eine URL.“ Im App Router repräsentiert ein Ordner ein Segment, benötigt aber page.tsx oder route.ts, um zu einer öffentlichen Seite oder einem API-Endpunkt zu werden. Diese Regel ermöglicht es, zusammengehörige interne Dateien gemeinsam im Routenordner abzulegen. nextjs.org↗

Das zweite Missverständnis lautet: „Ohne Unterstrich-Ordner sind alle internen Dateien freigegeben.“ Gewöhnliche Dateien im App Router sind standardmäßig keine Routen. Ein Name wie _components ist keine erforderliche Sicherheitsfunktion, sondern ein Organisationswerkzeug, das interne Implementierung kennzeichnet und den Ordner vom Routing ausschließt. nextjs.org↗

Das dritte Missverständnis lautet: „Namen von Routengruppen gehören ebenfalls zu URLs.“ Der Name in Klammern in (marketing) wird aus der URL ausgeschlossen. Aufgrund dieser praktischen Eigenschaft sollten Sie sicherstellen, dass unterschiedliche Gruppen nicht dieselbe endgültige URL erzeugen. Wenn Sie mehrere Root-Layouts aufteilen, ist die Möglichkeit eines vollständigen Seitenladevorgangs beim Navigieren zwischen Gruppen ein weiterer Punkt, den Sie vor dem Strukturentwurf berücksichtigen sollten. nextjs.org↗

Vermeiden Sie schließlich den Fehler, bei der Einführung von src gleichnamige app- oder pages-Verzeichnisse sowohl im Stamm als auch in src zu behalten. Da in diesem Fall das Stammverzeichnis Vorrang hat, kann es so wirken, als würde der erwartete Quellcode nicht ausgeführt. Eine Strukturänderung ist nicht einfach die Aufgabe, alle Ordner auf einmal hinzuzufügen; gehen Sie schrittweise vor und prüfen Sie, welches Verzeichnis tatsächlich als Grundlage für das Routing dient. nextjs.org↗

Fazit: Der Standard betrifft Rollengrenzen, nicht eine Ordnerliste

Der Ausgangspunkt für eine Next.js-Projektstruktur sind die durch app und spezielle Dateien definierten Routing-Konventionen. In einem neuen App-Router-Projekt können Sie src/app zum Zentrum für URLs, Seiten und Layouts machen, public als Ordner für statische Assets im Stamm behalten und components, features, lib, hooks sowie types entsprechend dem tatsächlichen Umfang der Codewiederverwendung und der Komplexität der Domäne wählen. nextjs.org↗nextjs.org↗

Letztlich ist eine gute Struktur nicht diejenige mit den meisten Ordnern. Sie ermöglicht Teammitgliedern, den Speicherort eines Bildschirms für eine bestimmte Route, den diesem Bildschirm gewidmeten Code und an mehreren Stellen gemeinsam genutzten Code leicht vorherzusagen. Befolgen Sie die Dateikonventionen von Next.js genau und passen Sie den darüberliegenden Organisationsansatz anschließend schrittweise an, wenn sich Wachstumstempo und Änderungsmuster des Projekts entwickeln.