Fullstack-Design-Patterns-Leitfaden

Was macht Fullstack-Design-Patterns-Leitfaden?

Verwenden Sie dieses Skill, um End-to-End-Fullstack-Systeme zu beraten, zu architektonieren und zu refaktorieren. Wenden Sie Muster streng nur dann an, wenn eine identifizierbare architektonische Reibung vorliegt – nicht für spekulative Abstraktion.

Kernprinzipien

1. Problem-orientierte Auswahl: Führen Sie niemals ein Entwurfsmuster ein, ohne dass eine explizite architektonische Reibung oder ein Code-Geruch vorliegt (z. B. Prop Drilling, aufgeblähte Gottkomponenten, enge API-Kopplung, untestbare Logik, kaskadierende Netzwerkausfälle).
2. Klare architektonische Schnittstellen: Halten Sie klare Grenzen zwischen:
   • View / Darstellung: Dumme, deklarative Komponenten, die über Props gesteuert werden.
   • Client-State & Interaktion: Headless Hooks, zentrale Stores und Server-State-Caching.
   • API / Vertragsschicht: Typisierte Schemata, DTO-Adapter und Anti-Corruption-Schichten.
   • Domäne & Datenzugriff: Entkoppelte Geschäftsregeln und repositorygestützter Datenbankzugriff.
3. Über-Engineering vermeiden: Wenden Sie keine komplexen Unternehmensabstraktionen (wie Micro-Frontends, CQRS oder verteiltes Pub/Sub) auf einfache CRUD-Seiten oder Standard-Webanwendungen an.

---

Muster-Entscheidungsmatrix & Auslöser-Heuristiken

Ebene	Symptom / Reibung im Codebase	Empfohlenes Muster	Architektonische Nahtstelle
Frontend UI	Gottkomponente mischt API-Abruf, Formatierung und JSX-Layout	Container / Presentational	UI-Rendering von Datenabruf trennen
Frontend UI	Eng gekoppeltes Styling innerhalb interaktiver Komponenten (Modals, Dropdowns)	Headless-Komponente / Custom Hooks	State sowie Tastatur-/Interaktionslogik isolieren
Frontend UI	Starre Komponenten-APIs, die flexible Unterelemente benötigen	Compound Components	Deklarative Eltern-Kind-State-Weitergabe (z. B. Tabs, Select)
Frontend UI	Tiefes Prop Drilling oder nicht synchronisierte Multi-Komponenten-UI-Zustände	Observer / Store (Zustand/Redux/Context)	Gemeinsamen Client-State zentralisieren
Fullstack API	Backend-API-Schemaänderungen brechen Frontend-UI-Komponenten	Adapter Pattern (Data Mapper)	Anti-Corruption-Layer, der DTO in View Model übersetzt
Fullstack API	UI wartet auf langsame Netzwerke, bevor Benutzeraktion bestätigt wird	Optimistic UI mit Rollback	Sofortige UI-Antwort, gestützt durch transaktionales Rollback
Backend	SQL/ORM-Aufrufe verstreut in Route-Handlern oder Services	Repository Pattern	Persistenzabfragen von Geschäftsregeln entkoppeln
Backend	Instanziierung verschiedener Drittanbieter-SDKs mittels inline if-else	Factory Pattern	Objekt- und Client-Erstellung zentralisieren
Backend	Kaskadierende if-else / switch zur Berechnung von Preisen, Auth oder Algorithmen	Strategy Pattern	Austauschbare Algorithmen hinter einem Interface kapseln
Backend / Verteilt	Kern-Geschäftsaktion löst 5+ unabhängige Seiteneffekte aus	Observer / Event-Driven (Pub/Sub)	Seiteneffekte über Domain-Events oder Nachrichtenwarteschlangen entkoppeln
Backend / Verteilt	Externe API-Latenz führt zu Thread-Starvation und kaskadierenden Ausfallzeiten	Circuit Breaker	Schnell-Fehlschlag, Fallback-Antwort und Health-Check nachgelagerter Dienste

---

Vertiefung: Fullstack-Muster & Implementierungsregeln

1. Frontend: Container / Presentational Pattern

• Kontext: Komponenten wachsen über 200 Zeilen, indem sie useEffect, Queries, Datentransformationen und Layout-JSX kombinieren.
• Regeln:
  • Presentational-Komponente: Erhält Daten und Callbacks ausschließlich über Props; rein, einfach in Storybook ohne API-Mocks testbar.
  • Container (oder Page Hook): Ruft Serverdaten ab, verwaltet Lade-/Fehlerzustände und reicht transformierte Daten nach unten weiter.

2. Frontend: Headless Component & Custom Hook Pattern

• Kontext: Komplexe interaktive Verhaltensweisen (Autocomplete, mehrstufige Assistenten, Accordion), die über verschiedene visuelle Designs hinweg wiederverwendet werden müssen.
• Regeln:
  • State, Tastatur-Handler und ARIA-Attribute in einen headless Custom Hook extrahieren (z. B. useAutocomplete, useDisclosure).
  • Styling und DOM-Markup vollständig in der Hand des Konsumenten lassen.

3. Frontend: Compound Components

• Kontext: Komponenten mit tief verwandten Unterteilen, die kohärenten internen Zustand benötigen, ohne dutzende Konfigurations-Props zu übergeben.
• Regeln:
  • React Context nutzen, um implizit zwischen Eltern und Kind zu kommunizieren (<Accordion><Accordion.Item /><Accordion.Panel /></Accordion>).

4. Integration: Adapter Pattern (Anti-Corruption Layer)

• Kontext: Drittanbieter-REST/GraphQL-Payloads sickern direkt in UI-Komponenten-Props oder Kern-Domänenmodelle.
• Regeln:
  • Niemals zulassen, dass rohe Backend-DTO-Schlüssel die Prop-Strukturen von Frontend-Komponenten bestimmen.
  • Explizite Mapper-Funktionen erstellen (z. B. toUserViewModel(dto: UserApiDto): UserVM), um UI-Komponenten vor Schemaänderungen zu schützen.

5. Integration: Optimistic UI mit Rollback

• Kontext: Häufige Benutzerinteraktionen (Likes, Umschalter, Aufgabenerledigung, Neuanordnung), bei denen Netzwerklatenz die Reaktionsfähigkeit beeinträchtigt.
• Regeln:
  • Lokalen Zustand sofort nach der Interaktion aktualisieren.
  • Server-Mutation in die Warteschlange stellen; bei Ablehnung auf den vorherigen Snapshot zurückrollen und den Benutzer nicht-intrusiv benachrichtigen.

6. Backend: Repository Pattern

• Kontext: Geschäftslogik ist mit ORM-Abfragen (Prisma, TypeORM, Drizzle, SQL) verwoben.
• Regeln:
  • Services interagieren ausschließlich über ein Interface (z. B. OrderRepository).
  • Domänenlogik aus Repositories heraushalten; Query-Erstellung aus Services heraushalten.

7. Backend: Strategy & Factory Patterns

• Kontext: Austauschbare Anbieter (Zahlungs-Gateways, Benachrichtigungskanäle, Dateispeicher).
• Regeln:
  • Verhalten über ein gemeinsames Interface standardisieren (PaymentGateway).
  • Factory/Registry verwenden, um konkrete Implementierungen basierend auf Konfiguration oder Mandant aufzulösen.

8. Backend: Circuit Breaker Pattern

• Kontext: Externe Microservices oder Drittanbieter-APIs leiden unter zeitweiligen Ausfällen oder starker Latenz.
• Regeln:
  • Fehlerschwellen verfolgen. Übergänge: Closed (normal) -> Open (Schnell-Fehlschlag, gecachte/Fallback-Antwort zurückgeben) -> Half-Open (Canary-Probe).

---

Agenten-Ausgabe-Workflow

Wenn Sie um Beratung zur Architektur oder Refaktorierung von Fullstack-Code gebeten werden:

1. Nahtstelle & Engpass identifizieren: Lokalisieren Sie, ob die Reibung im UI-Rendering, in der Zustandssynchronisation, im API-Vertragskonflikt oder in der Backend-Kopplung liegt.
2. Passendes Muster auswählen: Schlagen Sie das Muster mit einer klaren Begründung vor, die auf den spezifischen Code-Geruch eingeht.
3. Vorher / Nachher-Beispiele liefern: Geben Sie präzise, idiomatische Codeausschnitte, die die entkoppelten Verantwortlichkeiten demonstrieren.
4. Testbarkeit & Wartbarkeit hervorheben: Erklären Sie, wie die Refaktorierung Unit-/Komponententests vereinfacht und gegen zukünftige Änderungen abschirmt.