Frontend Academy · Lektion

Featurebasierte Ordnerstruktur

Organisieren Sie Code nach fachlichen Features statt nach Typ, legen Sie Tests, Styles und Komponenten gemeinsam ab und setzen Sie mit eslint-plugin-boundaries Grenzen durch.

Featurebasierte Ordnerstruktur ist eine kostenlose Frontend Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Frontend Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Zwei Möglichkeiten, Code zu strukturieren

Sie können Code nach Typ (components/, hooks/, services/, types/) oder nach Feature (auth/, checkout/, dashboard/ — jeweils mit eigenen components, hooks usw.) gruppieren. Für mittelgroße bis große Apps ist die Strukturierung nach Features meist besser.

Nach Typ — die Standardfalle

Die klassische Struktur aus React-Tutorials gruppiert alles nach Typ. Sie skaliert schlecht: Jede Dateiänderung betrifft mehrere voneinander unabhängige Ordner, und „allen Checkout-Code finden“ bedeutet, den gesamten Verzeichnisbaum mit grep zu durchsuchen.

// Type-based (avoid for large apps):
src/
  components/
    Button.tsx
    LoginForm.tsx
    CartItem.tsx
  hooks/
    useAuth.ts
    useCart.ts
  services/
    auth.ts
    cart.ts
  types/
    User.ts
    CartItem.ts

Strukturierung nach Features

Gruppieren Sie alles, was zu einem Feature gehört, in einem Ordner. So ist der Code leicht zu finden, leicht zu löschen und einfach nachzuvollziehen.

src/
  features/
    auth/
      LoginForm.tsx
      SignupForm.tsx
      useAuth.ts
      auth.service.ts
      auth.types.ts
      auth.test.tsx
    cart/
      CartItem.tsx
      CartSummary.tsx
      useCart.ts
      cart.service.ts
      cart.types.ts
  shared/
    components/
      Button.tsx
    hooks/
      useDebounce.ts

Co-Location innerhalb eines Features

Ein Feature-Ordner enthält components, hooks, services, types und tests — den gesamten für diese Domäne benötigten Code. Möchte ein neuer Entwickler auth verstehen? Öffnen Sie auth/. Möchten Sie auth löschen? Löschen Sie den Ordner.

Shared vs. Feature

Code, der von mindestens zwei Features verwendet wird, kommt nach shared/ (oder lib/). Code, der nur von einem Feature verwendet wird, bleibt dort. Widerstehen Sie der Versuchung „könnte später wiederverwendbar sein“ — warten Sie mit dem Herauslösen, bis es eine zweite Verwendung gibt.

Regeln für Feature-Grenzen

Features sollten nicht direkt voneinander importieren. Wenn zwei Features Code gemeinsam benötigen, wird dieser nach shared/ verschoben. Müssen sie sich koordinieren, verwenden Sie Events oder einen gemeinsamen Store auf App-Ebene.

Grenzen mit ESLint durchsetzen

Verwenden Sie eslint-plugin-boundaries oder eslint-plugin-import, um Folgendes durchzusetzen: Features dürfen aus shared importieren, aber nicht voneinander.

// .eslintrc.json
{
  "plugins": ["boundaries"],
  "settings": {
    "boundaries/elements": [
      { "type": "feature", "pattern": "src/features/*" },
      { "type": "shared",  "pattern": "src/shared/*" }
    ]
  },
  "rules": {
    "boundaries/element-types": ["error", {
      "default": "disallow",
      "rules": [
        { "from": "feature", "allow": ["shared"] },
        { "from": "shared",  "allow": ["shared"] }
      ]
    }]
  }
}

Öffentliche API pro Feature

Jedes Feature stellt über features/auth/index.ts eine öffentliche API bereit. Anderer Code importiert aus '@/features/auth' statt über tiefe Pfade. So können Sie die Interna umstrukturieren, ohne die Nutzer zu beeinträchtigen.

// features/auth/index.ts
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User, AuthState } from './auth.types';

// Consumers:
import { LoginForm, useAuth } from '@/features/auth';
// NOT: import { LoginForm } from '@/features/auth/LoginForm';

Verschachtelte Subfeatures

Große Features können Unterordner enthalten: dashboard/widgets/, dashboard/charts/. Vermeiden Sie mehr als 2–3 Verschachtelungsebenen — die Suche wird sonst mühsam.

Wo Routen liegen

Pages und Routes können in einem übergeordneten Ordner pages/ oder routes/ liegen. Sie sind schlank — sie beziehen Komponenten und Hooks aus Features und setzen sie zusammen.

src/
  pages/
    Dashboard.page.tsx   // composes Dashboard widgets from features/dashboard/
    Cart.page.tsx        // composes from features/cart/
  features/
  shared/

Eine bestehende App migrieren

Beginnen Sie nur mit neuen Features — legen Sie neuen Code in features/ ab. Strukturieren Sie nicht alles auf einmal um. Wenn Sie alte Dateien bearbeiten, verschieben Sie sie schrittweise. ESLint-Regeln für Grenzen verhindern Rückfälle in der neuen Struktur.

Wann eine Strukturierung nach Typ weiterhin funktioniert

Für sehr kleine Apps (mit weniger als 30 Komponenten) oder Bibliotheken ist die Strukturierung nach Typ völlig in Ordnung. Verwenden Sie die Strukturierung nach Features, sobald Sie klar getrennte Geschäftsdomänen haben (auth, checkout, billing, settings).

Wissenscheck

Was ist der wichtigste organisatorische Vorteil, wenn Code nach Features statt nach Dateityp gruppiert wird?

Zusammenfassung: Strukturierung nach Features

features/ enthält domänenspezifischen Code; shared/ enthält featureübergreifende Hilfsfunktionen. Jedes Feature stellt eine öffentliche index.ts bereit. Features importieren nicht voneinander — nur aus shared. Setzen Sie dies mit eslint-plugin-boundaries durch. Pages und Routes setzen Features zusammen. Migrieren Sie schrittweise. Für kleine Apps ist die Strukturierung nach Typ in Ordnung.

Häufig gestellte Fragen

Ist die Lektion „Featurebasierte Ordnerstruktur“ kostenlos?

Ja — der vollständige Text von „Featurebasierte Ordnerstruktur“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Frontend Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Featurebasierte Ordnerstruktur“?

Organisieren Sie Code nach fachlichen Features statt nach Typ, legen Sie Tests, Styles und Komponenten gemeinsam ab und setzen Sie mit eslint-plugin-boundaries Grenzen durch. Du übst Frontend Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Frontend Academy zu starten?

Keine Vorkenntnisse erforderlich. Frontend Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Featurebasierte Ordnerstruktur“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Frontend Academy-Lektion Code schreiben und ausführen?

Ja. Jede Frontend Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Atomic Design: Atome, Moleküle und Organismen
Monorepo-Einrichtung mit Turborepo
Micro-frontends: Module Federation
Featurebasierte Ordnerstruktur

← Zurück zu Frontend Academy