AI für Code-Architektur & Design Patterns

AI für Code-Architektur & Design Patterns: SOLID, Clean Architecture und Patterns mit ChatGPT & Claude. 10 Prompts für bessere Software-Architektur.

Einleitung

Gute Architektur entscheidet über die Wartbarkeit deines Projekts. AI kennt alle Patterns und kann sie auf deinen konkreten Use Case anwenden. Hier sind 10 Prompts für Code-Architektur und Design Patterns.

Prompt 1: SOLID Prinzipien

Erkläre und wende SOLID Prinzipien auf meinen Code an:

Code:
```
[CODE HIER EINFÜGEN]
```

Analysiere für jedes Prinzip:
1. **S – Single Responsibility**: Hat die Klasse/Funktion nur eine Aufgabe?
   → Wo wird SRP verletzt? Wie aufteilen?
2. **O – Open/Closed**: Kann erweitert werden ohne Änderung?
   → Extension Points hinzufügen (Strategy, Plugin)
3. **L – Liskov Substitution**: Können Subtypen den Basistyp ersetzen?
   → Vererbungs-Hierarchie prüfen
4. **I – Interface Segregation**: Sind Interfaces zu groß?
   → Kleine, fokussierte Interfaces statt God-Interface
5. **D – Dependency Inversion**: Hängt High-Level von Low-Level ab?
   → Dependency Injection einführen

Pro Prinzip:
6. Konkretes Beispiel aus meinem Code
7. Vorher/Nachher Refactoring
8. Warum es wichtig ist (konkreter Nutzen)
9. Wann es NICHT anwenden (Over-Engineering)
10. TypeScript-idiomatische Lösung

Prompt 2: Clean Architecture

Implementiere Clean Architecture für mein Projekt:

Projekt: [z.B. "E-Commerce API mit Node.js/TypeScript"]
Aktuell: [z.B. "Alles in Controller, keine Schichten"]

Strukturiere in Schichten:
1. **Entities**: Domain Models (User, Product, Order)
2. **Use Cases**: Business Logic (CreateOrder, ProcessPayment)
3. **Interfaces**: Ports (UserRepository Interface, PaymentGateway)
4. **Adapters**: Implementierungen (PrismaUserRepository, StripePayment)
5. **Framework**: Express Routes, Middleware, DB Config

Implementiere:
6. **Dependency Rule**: Innere Schichten kennen äußere nicht
7. **Dependency Injection**: Constructor Injection
8. **DTOs**: Daten-Transformation zwischen Schichten
9. **Error Handling**: Domain Errors vs. Infrastructure Errors
10. **Ordner-Struktur**: Practical Clean Architecture in TypeScript

Pragmatische Variante:
- Nicht dogmatisch – 100% Clean Architecture ist Over-Engineering
- Für kleine Projekte: Service Layer + Repository reicht
- Clean Architecture vor allem für Business-kritische Domains

Prompt 3: Creational Patterns

Erkläre und implementiere Creational Design Patterns:

Sprache: [TypeScript / JavaScript / Python]
Kontext: [z.B. "Web Application, verschiedene Services erstellen"]

Implementiere mit Praxisbeispielen:
1. **Factory Method**: createNotification('email') → EmailNotification
2. **Abstract Factory**: UI-Komponenten für verschiedene Themes
3. **Builder**: Komplexe Query/Config Objekte schrittweise bauen
4. **Singleton**: Datenbank Connection Pool, Logger
5. **Prototype**: Object.create() für tiefes Klonen

Pro Pattern:
6. Wann verwenden? (Use Case)
7. TypeScript Implementation
8. Moderne Alternative (oft reicht eine Function!)
9. Unit Test für das Pattern
10. Wann NICHT verwenden (Over-Engineering-Warnung)

Modern TypeScript Perspektive:
- Factory Function statt Factory Class
- Module Scope statt Singleton Class
- Plain Objects + Spread statt Prototype
- Builder Pattern bleibt relevant!

Prompt 4: Structural Patterns

Erkläre und implementiere Structural Design Patterns:

Sprache: [TypeScript / JavaScript]
Kontext: [z.B. "Frontend + Backend einer Web App"]

Implementiere:
1. **Adapter**: Legacy API → Neue API Schnittstelle anpassen
2. **Facade**: Komplexes Subsystem hinter einfachem Interface
3. **Proxy**: Logging Proxy, Caching Proxy, Auth Proxy
4. **Decorator**: Funktionalität hinzufügen (Logger, Cache, Retry)
5. **Composite**: Baumstrukturen (Menü, Dateisystem, UI Components)

Pro Pattern:
6. **Real-World Beispiel**: Wo begegnet mir das täglich?
7. **TypeScript Implementation**: Mit Generics und Types
8. **Funktionaler Ansatz**: HOF statt Klassen (Decorator → Wrapper Function)
9. **React-Beispiel**: HOC, Render Props, Custom Hooks als Patterns
10. **Wann nicht**: Einfachheit > Pattern-Perfektion

Alltagsbeispiele:
- Adapter: axios → fetch Migration
- Facade: Stripe Client mit nur 3 Methoden statt 100
- Proxy: React.lazy() ist ein Lazy Loading Proxy
- Decorator: Express Middleware = Decorator Pattern

Prompt 5: Behavioral Patterns

Erkläre und implementiere Behavioral Design Patterns:

Sprache: [TypeScript / JavaScript]
Kontext: [z.B. "Event-System, State Management, Workflows"]

Implementiere:
1. **Observer/PubSub**: Event Emitter, React State Updates
2. **Strategy**: Verschiedene Algorithmen austauschbar (Sort, Validate)
3. **Command**: Undo/Redo System, Queue-verarbeitete Aktionen
4. **State Machine**: Order Status, Auth Flow, Wizard Steps
5. **Chain of Responsibility**: Middleware Pipeline (Express, Next.js)

Pro Pattern:
6. **Template Method**: Basis-Workflow mit austauschbaren Schritten
7. **Iterator**: Custom Iteratoren mit Symbol.iterator
8. **Mediator**: Zentraler Event Bus, Chat Room
9. **Real-World**: Wo verwenden populäre Libraries diese Patterns?
10. **TypeScript**: Type-safe State Machines mit Discriminated Unions

Moderne Equivalente:
- Observer → RxJS, EventEmitter, Zustand Subscribe
- Strategy → Functions als Parameter
- State Machine → XState, Zustand
- Command → Redux Actions, Event Sourcing

Prompt 6: Frontend Patterns

Erkläre Frontend-spezifische Architektur-Patterns:

Framework: [React / Vue / Svelte]
Projekt: [z.B. "Dashboard App mit vielen Features"]

Implementiere:
1. **Component Composition**: Kleine, zusammensetzbare Komponenten
2. **Container/Presentational**: Logic und UI trennen
3. **Custom Hooks**: Wiederverwendbare State-Logik
4. **Render Props**: Flexible Rendering-Delegation
5. **Compound Components**: Select + Option Pattern
6. **State Management**: Local → Context → Global (Zustand/Redux)
7. **Feature-based Structure**: Pro Feature ein Ordner
8. **Barrel Exports**: index.ts für saubere Imports
9. **Error Boundaries**: Fehler pro Feature abfangen
10. **Optimistic Updates**: UI sofort aktualisieren

React-spezifisch:
- Server Components vs. Client Components
- Suspense für Data Fetching
- React.lazy für Code Splitting
- Key Pattern für List Rendering

Prompt 7: Backend Patterns

Erkläre Backend-spezifische Architektur-Patterns:

Stack: [z.B. "Node.js, TypeScript, Prisma"]
Typ: [Monolith / Microservices / Modular Monolith]

Implementiere:
1. **Repository Pattern**: Datenzugriff abstrahieren
2. **Service Layer**: Business Logic zentralisieren
3. **CQRS**: Command/Query Responsibility Segregation
4. **Event Sourcing**: Zustand aus Events ableiten
5. **Unit of Work**: Transaktionen verwalten
6. **Middleware Pipeline**: Request → Middleware → Handler
7. **Saga Pattern**: Verteilte Transaktionen koordinieren
8. **Circuit Breaker**: Externe Services absichern
9. **Retry Pattern**: Fehlerhafte Calls wiederholen
10. **Bulkhead**: Services voneinander isolieren

Pragmatisch:
- Monolith starten, Modular Monolith wenn nötig
- Repository + Service = reicht für 80% der Projekte
- CQRS/Event Sourcing nur bei Business-Anforderung
- Over-Engineering ist das größte Architektur-Problem!

Prompt 8: Domain-Driven Design

Wende Domain-Driven Design auf mein Projekt an:

Domain: [z.B. "E-Commerce: Bestellungen, Zahlung, Versand"]
Komplexität: [z.B. "Mittel – mehrere Bounded Contexts"]

Implementiere DDD Konzepte:
1. **Ubiquitous Language**: Glossar der Domain-Begriffe
2. **Bounded Contexts**: Kontextgrenzen definieren (Order, Payment, Shipping)
3. **Entities**: Objekte mit Identität (Order, User)
4. **Value Objects**: Wert ohne Identität (Money, Address, Email)
5. **Aggregates**: Konsistenz-Grenzen (Order + OrderItems)
6. **Domain Events**: OrderPlaced, PaymentReceived
7. **Repositories**: Aggregate Root laden/speichern
8. **Domain Services**: Logik die keinem Entity gehört
9. **Application Services**: Use Cases orchestrieren
10. **Context Mapping**: Wie kommunizieren Bounded Contexts?

Pragmatisches DDD:
- Nicht alles ist DDD – CRUD Endpoints brauchen kein DDD
- DDD für komplexe Business-Domains
- Value Objects und Domain Events: Quick Wins!
- Aggregate Design: Die schwierigste Aufgabe

Prompt 9: Pattern-basiertes Refactoring

Refactore meinen Code mit dem richtigen Design Pattern:

Code:
```
[CODE HIER EINFÜGEN]
```

Problem: [z.B. "Riesiges Switch Statement mit 20 Cases"]

Analysiere:
1. **Code Smell identifizieren**: Welcher Smell liegt vor?
2. **Pattern auswählen**: Welches Pattern löst das Problem?
3. **Schrittweises Refactoring**: Sicherer Übergang
4. **Vorher/Nachher**: Vergleich der Lösung
5. **Tests erhalten**: Bestehende Tests dürfen nicht brechen

Häufige Refactorings:
6. Switch → Strategy Pattern
7. Verschachtelte Ifs → Chain of Responsibility / State Machine
8. God Class → SRP + Facade
9. Callback Hell → Command / Async Pipeline
10. Copy-Paste Code → Template Method / Strategy

Warnung: Nicht jedes Problem braucht ein Pattern!
Manchmal ist eine einfache Funktion die beste Lösung.
Pattern nur wenn es die Wartbarkeit WIRKLICH verbessert.

Prompt 10: Anti-Patterns erkennen

Prüfe meinen Code auf Anti-Patterns:

Code:
```
[CODE HIER EINFÜGEN]
```

Prüfe auf:
1. **God Object/God Class**: Eine Klasse die alles macht
2. **Spaghetti Code**: Unkontrollierter Kontrollfluss
3. **Shotgun Surgery**: Eine Änderung → 10 Dateien ändern
4. **Feature Envy**: Klasse nutzt mehr fremde als eigene Daten
5. **Primitive Obsession**: Strings statt Value Objects (Email, Money)
6. **Anemic Domain Model**: Entities ohne Logik + Service-Klasse
7. **Golden Hammer**: Ein Tool/Pattern für alles
8. **Premature Optimization**: Optimierung ohne Messung
9. **Cargo Cult**: Patterns ohne Verständnis kopiert
10. **Not Invented Here**: Alles selbst bauen statt Libraries

Pro Anti-Pattern:
- Erkennung: Wie sehe ich es im Code?
- Problem: Warum ist es schlecht?
- Lösung: Wie refactore ich es weg?
- Beispiel aus meinem Code

FAQ

Muss ich alle Design Patterns kennen?

Nein – die wichtigsten im Alltag: Strategy, Observer, Factory, Builder, Decorator, Adapter, Facade. Die GoF 23 auswendig kennen ist nicht nötig. Verstehe die Prinzipien (SOLID, DRY, KISS) und wende Patterns an wenn sie ein echtes Problem lösen.

Wie vermeide ich Over-Engineering?

Faustregel: Wenn du ein Pattern einführst und du der einzige bist der es versteht → zu komplex. Start simple, refactore wenn nötig. YAGNI (You Ain’t Gonna Need It). Pattern einführen erst wenn der Pain offensichtlich ist, nicht „just in case“.

Kann AI mir helfen bessere Architektur zu schreiben?

AI kennt alle Patterns und kann sie auf deinen Code anwenden. Paste Code und frage „Welches Pattern passt hier?“. AI kann SOLID-Verletzungen finden, Refactoring vorschlagen und Clean Architecture implementieren. Am besten: Code zeigen und fragen, nicht nur theoretisch diskutieren.

Verwandte Artikel:

Zuletzt aktualisiert: März 2026