viccom/software-architecture-design

Softwarearchitektur-Design — Kurzreferenz

Verwenden Sie diesen Skill für systemweite Designentscheidungen anstelle von Implementierungsdetails innerhalb eines einzelnen Dienstes oder einer Komponente.

Kurzreferenz

Aufgabe	Muster/Werkzeug	Wichtige Ressourcen	Wann verwenden
Architekturstil wählen	Geschichtet, Microservices, Ereignisgesteuert, Serverlos	modern-patterns.md	Greenfield-Projekte, große Refactorings
Für Skalierung entwerfen	Load-Balancing, Caching, Sharding, Read-Replicas	scalability-reliability-guide.md	Systeme mit hohem Traffic, Leistungsziele
Ausfallsicherheit gewährleisten	Circuit Breaker, Retries, Bulkheads, Graceful Degradation	scalability-reliability-guide.md	Verteilte Systeme, externe Abhängigkeiten
Entscheidungen dokumentieren	Architecture Decision Record (ADR)	adr-template.md	Wichtige technische Entscheidungen, Trade-off-Analyse
Service-Grenzen definieren	Domain-Driven Design (DDD), Bounded Contexts	microservices-template.md	Microservices-Zerlegung
Datenkonsistenz modellieren	ACID vs. BASE, Event Sourcing, CQRS, Saga-Muster	data-architecture-patterns.md	Transaktionen über mehrere Dienste hinweg
Observability planen	SLIs/SLOs/SLAs, Verteiltes Tracing, Metriken, Logs	architecture-blueprint.md	Produktionsreife
Vom Monolithen migrieren	Strangler Fig, Datenbankzerlegung, Shadow Traffic	migration-modernization-guide.md	Legacy-Modernisierung
Dienstekommunikation entwerfen	API-Gateway, Service Mesh, BFF-Muster	api-gateway-service-mesh.md	Microservices-Netzwerkarchitektur

Wann dieser Skill verwendet werden sollte

Rufen Sie ihn auf, wenn Sie an Folgendem arbeiten:

• Systemzerlegung: Entscheidung zwischen Monolith, modularer Monolith, Microservices
• Architekturmuster: Ereignisgesteuert, CQRS, geschichtet, hexagonal, serverlos
• Datenarchitektur: Konsistenzmodelle, Sharding, Replikation, CQRS-Muster
• Skalierbarkeitsdesign: Load-Balancing, Caching-Strategien, Datenbankskalierung
• Resilienzmuster: Circuit Breaker, Retries, Bulkheads, Graceful Degradation
• API-Verträge: Service-Grenzen, Versionierung, Integrationsmuster
• Architekturentscheidungen: ADRs, Trade-off-Analyse, Technologieauswahl
• Migrationsplanung: Monolith-Zerlegung, Strangler Fig, Datenbanktrennung

Wann dieser Skill NICHT verwendet werden sollte

Verwenden Sie stattdessen andere Skills für:

• Einzeldienst-Implementierung (Routen, Controller, Geschäftslogik) → software-backend
• API-Endpunkt-Design (REST-Konventionen, GraphQL-Schemas) → dev-api-design
• Sicherheitsimplementierung (Auth, Verschlüsselung, OWASP) → software-security-appsec
• Frontend-Komponentenarchitektur → software-frontend
• Datenbankabfrageoptimierung → data-sql-optimization

Entscheidungsbaum: Architekturmuster auswählen

Projektanforderungen: [Neues System oder großes Refactoring]
    ├─ Ein Team, sich entwickelnde Domäne?
    │   ├─ Einfach starten → Modularer Monolith (klare Modulgrenzen)
    │   └─ Schnelle Iteration nötig → Geschichtete Architektur
    │
    ├─ Mehrere Teams, klare Bounded Contexts?
    │   ├─ Unabhängige Bereitstellung kritisch → Microservices
    │   └─ Gemeinsames Datenmodell → Modularer Monolith mit Servicemodulen
    │
    ├─ Ereignisgesteuerte Workflows?
    │   ├─ Asynchrone Verarbeitung → Ereignisgesteuerte Architektur (Kafka, Queues)
    │   └─ Komplexe Zustandsmaschinen → Saga-Muster + Event Sourcing
    │
    ├─ Variable/unvorhersehbare Last?
    │   ├─ Pay-per-Use-Modell → Serverlos (AWS Lambda, Cloudflare Workers)
    │   └─ Batch-Verarbeitung → Serverlos + Queues
    │
    └─ Hohe Konsistenzanforderungen?
        ├─ Starke ACID-Garantien → Monolith oder Modularer Monolith
        └─ Verteilte Daten → CQRS + Event Sourcing

Entscheidungsfaktoren:

• Teamgrößen-Schwelle: <10 Entwickler → Modularer Monolith ist in der Regel besser als Microservices (operativer Aufwand)
• Teamstruktur (Conway's Law) — Architektur spiegelt die Organisationsstruktur wider
• Anforderungen an die Bereitstellungsunabhängigkeit
• Konsistenz vs. Verfügbarkeit (CAP-Theorem)
• Operative Reife (Monitoring, Orchestrierung)

Ausführliche Musterbeschreibungen finden Sie in references/modern-patterns.md.

Ausgaberichtlinien

Die Referenzen in diesem Skill sind Hintergrundwissen für Sie — absorbieren Sie die Muster und präsentieren Sie sie als Ihr eigenes Fachwissen. Verweisen Sie nicht auf interne Referenzdateinamen (z. B. „aus data-architecture-patterns.md“) in der Ausgabe, die dem Benutzer gegenübersteht. Die Benutzer wissen nicht, dass diese Dateien existieren.

Jede Architekturempfehlung sollte Folgendes enthalten:

• Konkrete Technologieauswahl: Nennen Sie spezifische Technologien (z. B. „Temporal.io für Workflow-Orchestrierung“, „Socket.io mit Redis-Adapter“), anstatt abstrakt zu bleiben. Der Benutzer muss Bauentscheidungen treffen, nicht nur Muster verstehen.
• Was NICHT gebaut werden sollte: Machen Sie explizit klar, was aufgeschoben oder vermieden werden sollte. Vorzeitiger Scope ist der häufigste Architekturfehler – helfen Sie dem Benutzer, ihn zu vermeiden.
• Team- und Prozessausrichtung: Wie passt diese Architektur zur Teamstruktur? Welches Ownership-Modell impliziert sie? Geben Sie CODEOWNERS, Deployment-Ownership und On-Call-Grenzen an, wo relevant.
• Erfolgskennzahlen: Wie erkennt das Team, dass die Architektur funktioniert? Geben Sie messbare Indikatoren an (Deploy-Frequenz, Durchlaufzeit, Fehlerraten, MTTR).
• Fokussierte Länge: Zielen Sie auf Tiefe bei den 3–5 wichtigsten Entscheidungen ab, anstatt auf eine erschöpfende Abdeckung aller Belange. Eine Empfehlung, die zu lang zum Lesen ist, ist eine Empfehlung, die nicht befolgt wird.

Arbeitsablauf (Systemebene)

Verwenden Sie diesen Arbeitsablauf, wenn ein Benutzer Architekturempfehlungen, Zerlegungen oder große Plattformentscheidungen abfragt.

1. Klären: Problemstellung, Nicht-Ziele, Einschränkungen und Erfolgskennzahlen
2. Qualitätsattribute erfassen: Verfügbarkeit, Latenz, Durchsatz, Haltbarkeit, Konsistenz, Sicherheit, Compliance, Kosten
3. 2–3 Kandidatenarchitekturen vorschlagen und Trade-offs vergleichen
4. Grenzen definieren: Bounded Contexts, Ownership, APIs/Ereignisse, Integrationsverträge
5. Datenstrategie festlegen: Speicher, Konsistenzmodell, Schemaentwicklung, Migrationen
6. Für den Betrieb entwerfen: SLOs, Fehlermodi, Observability, Deployment, DR, Incident-Playbooks
7. Scope-Grenzen aufzeigen: was noch NICHT gebaut werden sollte, was aufgeschoben werden sollte, was gekauft vs. gebaut werden sollte
8. Entscheidungen dokumentieren: ADRs für wichtige Trade-offs und irreversible Entscheidungen schreiben

Bevorzugte Ergebnisse (wählen Sie, was zur Anfrage passt):

• Architektur-Blueprint: assets/planning/architecture-blueprint.md
• Entscheidungsdokument: assets/planning/adr-template.md
• Muster-Tiefenbohrungen: references/modern-patterns.md, references/scalability-reliability-guide.md

Überlegungen für 2026

Laden Sie diese nur, wenn die Frage explizit aktuelle Trends, anbieterspezifische Einschränkungen oder „Was ist der neueste Stand zu X?“ betrifft.

• references/architecture-trends-2026.md — Plattform-Engineering, Data Mesh, komponierbare Architektur, KI-native Systeme
• data/sources.json — 60 kuratierte Ressourcen, organisiert nach Kategorie:
  • platform_engineering_2026 — IDP-Trends, KI-Plattform-Konvergenz, Backstage
  • optional_ai_architecture — RAG-Muster, Multi-Agent-Design, MCP/A2A-Protokolle
  • modern_architecture_2025 — Data Mesh, komponierbare Architektur, kontinuierliche Architektur

Wenn Live-Webzugriff verfügbar ist, konsultieren Sie 2–3 maßgebliche Quellen aus data/sources.json und integrieren Sie die Ergebnisse in die Empfehlung. Wenn nicht, antworten Sie mit bewährten Mustern und machen Sie explizit Annahmen, die sich ändern könnten (Anbietergrenzen, Preise, Managed-Service-Funktionen).

Navigation

Kernreferenzen

Lesen Sie höchstens 2–3 Referenzen pro Frage – wählen Sie diejenigen aus, die für die spezifische Anfrage am relevantesten sind. Lesen Sie nicht alle davon.

Referenz	Inhalt	Wann lesen
modern-patterns.md	10 Architekturmuster mit Entscheidungsbäumen	Muster auswählen oder vergleichen
scalability-reliability-guide.md	CAP-Theorem, DB-Skalierung, Caching, Circuit Breaker, SRE	Skalierungs- oder Zuverlässigkeitsfragen
data-architecture-patterns.md	CQRS-Varianten, Event Sourcing, Data Mesh, Sagas, Konsistenz	Datenfluss über Dienste hinweg
migration-modernization-guide.md	Strangler Fig, DB-Zerlegung, Feature Flags, Risikobewertung	Monolithen refaktorieren
api-gateway-service-mesh.md	Gateway-Muster, Service Mesh, mTLS, Observability	Kommunikation zwischen Diensten
architecture-trends-2026.md	Plattform-Engineering, Data Mesh, KI-native Systeme	Nur aktuelle Trends
operational-playbook.md	Framework für Architekturfragen, Zerlegungsheuristiken	Rahmung von Design-Diskussionen

Vorlagen

Planung & Dokumentation (assets/planning/):

• architecture-blueprint.md — Service-Blueprint (Abhängigkeiten, SLAs, Datenflüsse, Resilienz, Sicherheit, Observability)
• adr-template.md — Architecture Decision Record für Trade-off-Analysen

Architekturmuster (assets/patterns/):

• microservices-template.md — Microservices-Design (API-Verträge, Resilienz, Deployment, Tests)
• event-driven-template.md — Ereignisgesteuerte Architektur (Ereignisschemas, Saga-Muster, Event Sourcing)

Betrieb (assets/operations/):

• scalability-checklist.md — Checkliste für Skalierbarkeit (DB-Skalierung, Caching, Lasttests, Auto-Scaling, DR)

Verwandte Skills

• software-backend — Backend-Engineering, API-Implementierung, Datenschicht
• software-frontend — Frontend-Architektur, Micro-Frontends, Zustandsverwaltung
• dev-api-design — REST-, GraphQL-, gRPC-Entwurfsmuster
• ops-devops-platform — CI/CD, Deployment-Strategien, IaC
• qa-observability — Monitoring, Tracing, Alerting, SLOs
• software-security-appsec — Bedrohungsmodellierung, Auth, sicheres Design
• data-sql-optimization — Datenbankdesign, Optimierung, Indizierung
• docs-codebase — Architekturdokumentation, C4-Diagramme, ADRs