Konformitäts-Regelpakete

Regelpakete sind kuratierte Sammlungen von Konformitätsregeln, die Best Practices für gängige Architekturmuster abbilden. Statt Regeln von Grund auf selbst zu schreiben, installieren Sie ein Paket und erhalten in Sekunden einen durchdachten, praxiserprobten Regelsatz.

Warum Regelpakete?

Die meisten Teams folgen bekannten Mustern — Microservices, Clean Architecture, ereignisgesteuerte Systeme. Jedes Muster bringt Einschränkungen mit sich, die automatisch durchgesetzt werden sollten:

• Microservices sollten sich keine Datenbanken teilen
• Domänenschichten sollten keinen Infrastrukturcode importieren
• Events sollten einem Schema-Vertrag folgen

Regelpakete machen aus diesen Prinzipien ausführbare Leitplanken.

Verfügbare Pakete

Ein Paket installieren

Über den archyl-developer-Skill

Bitten Sie Ihren KI-Coding-Agenten:

Install the microservices conformance rules pack

Der Agent ruft den Archyl MCP-Server auf und legt alle Regeln in einem einzigen Vorgang an.

Über das SDK

import { ArchylClient } from "@archyl/sdk";

const client = new ArchylClient({
  apiKey: process.env.ARCHYL_API_KEY,
  organizationId: "your-org-id",
});

// Install a pack by name
await client.governance.installPack("microservices");

Über die Benutzeroberfläche

Navigieren Sie zu Agent Hub > Packs und klicken Sie bei einem beliebigen Paket auf Installieren.

Was jedes Paket enthält

Microservices (10 Regeln)

• Keine gemeinsam genutzten Datenbanken — Jeder Service muss seine eigenen Daten besitzen. Service-übergreifende Abfragen nur über APIs.
• Unabhängige Deploybarkeit — Keine Abhängigkeiten zur Kompilierzeit zwischen Services. Gemeinsam genutzte Bibliotheken müssen versioniert sein.
• Begrenzte Kommunikation — Services kommunizieren über definierte API-Verträge oder Event-Kanäle, nicht über direkten Datenbankzugriff oder gemeinsam genutzte Dateien.
• Service-Isolation — Keine Service-übergreifenden Importe. Jeder Service hat seinen eigenen Abhängigkeitsbaum.

Clean Architecture (9 Regeln)

• Reinheit der Domänenschicht — Domänencode hat keinerlei externe Importe. Kein Framework, kein ORM, kein HTTP.
• Abhängigkeitsrichtung — Abhängigkeiten zeigen nach innen. Handler hängen von Services ab, Services von der Domäne, niemals umgekehrt.
• Durchsetzung von Ports/Adaptern — Infrastrukturbelange (DB, HTTP, Messaging) gehören in Adapter-Pakete, nicht in die Domänen- oder Service-Schicht.
• Schnittstellengrenzen — Services konsumieren Schnittstellen (Ports), keine konkreten Implementierungen.

Event-Driven (8 Regeln)

• Kanal-Konformität — Event-Produzenten und -Konsumenten müssen deklarierte Event-Kanäle verwenden. Keine spontan angelegten Topics.
• Schema-Anforderungen — Jedes Event muss ein definiertes Schema haben. Keine untypisierten Payloads.
• Dead Letter Queue — Konsumenten müssen eine DLQ für die Behandlung fehlgeschlagener Nachrichten konfigurieren.
• Namenskonventionen für Topics — Topics folgen einem einheitlichen Namensmuster (z. B. domain.entity.event).

API-First (8 Regeln)

• Vertrag erforderlich — Für jeden öffentlichen Endpoint muss ein OpenAPI-, gRPC- oder AsyncAPI-Vertrag hinterlegt sein.
• Versionierung — API-Endpoints müssen ein Versionspräfix enthalten (/v1/, /v2/).
• Dokumentation der Authentifizierung — Sicherheitsschemata müssen im Vertrag dokumentiert sein.
• Keine undokumentierten Endpoints — Handler-Dateien ohne zugehörige Vertragsdokumentation lösen eine Verletzung aus.

Security Baseline (8 Regeln)

• Gateway-Pflicht — Externer Datenverkehr muss über ein API-Gateway oder einen Load Balancer laufen. Keine direkte Exposition von Services.
• Secret-Verwaltung — Keine hartcodierten Secrets, API-Schlüssel oder Passwörter im Quellcode. Verwenden Sie Umgebungsvariablen oder einen Secret Manager.
• Zugriffskontrollen für externen Zugriff — Services, die externe Anfragen annehmen, müssen Authentifizierung und Rate Limiting erzwingen.
• TLS erforderlich — Die gesamte Kommunikation zwischen Services muss TLS verwenden. Kein unverschlüsseltes HTTP zwischen Services.

Regeln anpassen

Nach der Installation eines Pakets ist jede Regel vollständig bearbeitbar:

• Schweregrad ändern — Stufen Sie eine Regel von critical auf medium herab, wenn sie nicht zu Ihrer Risikotoleranz passt
• Einzelne Regeln deaktivieren — Schalten Sie Regeln, die Sie nicht benötigen, einzeln ab, ohne das gesamte Paket zu entfernen
• Konfiguration anpassen — Passen Sie Datei-Globs, Muster, erlaubte Importe oder Schichtdefinitionen an Ihre Projektstruktur an

Navigieren Sie zu Agent Hub und klicken Sie bei einer beliebigen Regel auf das Bearbeiten-Symbol, um sie zu ändern.

Pakete kombinieren

Pakete ergänzen sich. Installieren Sie mehrere Pakete, um unterschiedliche architektonische Belange abzudecken:

Enthalten zwei Pakete überlappende Regeln, dedupliziert Archyl sie — es entstehen keine Konflikte.

Mitwirken

Regelpakete sind Open Source. Sie können neue Pakete vorschlagen, bestehenden Paketen Regeln hinzufügen oder Probleme melden:

• github.com/archyl-com/agent-skills/rule-packs

Nächste Schritte

• Konformitätsregeln - Vollständiger Leitfaden zu Regeltypen und Konfiguration
• GitHub Actions - Konformitätsprüfungen in CI/CD ausführen