Packs de reglas de conformidad

Rules grouped by type, with packs and a browsable catalog

Los packs de reglas son colecciones curadas de reglas de conformidad que codifican buenas prácticas para patrones de arquitectura habituales. En lugar de escribir reglas desde cero, instala un pack y obtén en segundos un conjunto de reglas con criterio propio y probado en producción.

¿Por qué packs de reglas?

La mayoría de los equipos siguen patrones conocidos: microservicios, clean architecture, sistemas orientados a eventos. Cada patrón trae restricciones que deberían aplicarse automáticamente:

  • Los microservicios no deberían compartir bases de datos
  • Las capas de dominio no deberían importar código de infraestructura
  • Los eventos deberían seguir un contrato de esquema

Los packs de reglas convierten estos principios en guardrails ejecutables.

Packs disponibles

Pack Reglas Enfoque
Microservices 10 Límites entre servicios, despliegue independiente, comunicación acotada
Clean Architecture 9 Límites entre capas, aislamiento del dominio, aplicación de ports/adapters
Event-Driven 8 Cumplimiento de canales, requisitos de esquema, colas de mensajes fallidos
API-First 8 Requisitos de contrato, versionado, documentación de autenticación
Security Baseline 8 Uso obligatorio de gateway, gestión de secretos, controles de acceso externo

Instalar un pack

Con la skill archyl-developer

Pídeselo a tu agente de codificación de IA:

Install the microservices conformance rules pack

El agente llama al servidor MCP de Archyl y crea todas las reglas en una sola operación.

Con el 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");

Desde la interfaz

Ve a Hub de Agentes > Packs y haz clic en Instalar en cualquier pack.

Qué incluye cada pack

Microservices (10 reglas)

  • Sin bases de datos compartidas — Cada servicio debe ser dueño de sus datos. Las consultas entre servicios pasan solo por APIs.
  • Despliegue independiente — Sin dependencias en tiempo de compilación entre servicios. Las bibliotecas compartidas deben estar versionadas.
  • Comunicación acotada — Los servicios se comunican mediante contratos de API o canales de eventos definidos, no mediante acceso directo a la base de datos ni archivos compartidos.
  • Aislamiento de servicios — Sin imports entre servicios. Cada servicio tiene su propio árbol de dependencias.

Clean Architecture (9 reglas)

  • Pureza de la capa de dominio — El código de dominio no tiene ningún import externo. Ni frameworks, ni ORM, ni HTTP.
  • Dirección de las dependencias — Las dependencias apuntan hacia dentro. Los handlers dependen de los servicios y los servicios del dominio, nunca al revés.
  • Aplicación de ports/adapters — Los aspectos de infraestructura (base de datos, HTTP, mensajería) viven en paquetes adapter, no en las capas de dominio o de servicio.
  • Límites por interfaces — Los servicios consumen interfaces (ports), no implementaciones concretas.

Event-Driven (8 reglas)

  • Cumplimiento de canales — Los productores y consumidores de eventos deben usar los canales de eventos declarados. Nada de crear topics sobre la marcha.
  • Requisitos de esquema — Cada evento debe tener un esquema definido. Nada de payloads sin tipo.
  • Cola de mensajes fallidos — Los consumidores deben configurar una DLQ para gestionar los mensajes que fallan.
  • Convenciones de nombres de topics — Los topics siguen un patrón de nombres coherente (p. ej., domain.entity.event).

API-First (8 reglas)

  • Contrato obligatorio — Cada endpoint público debe tener registrado un contrato OpenAPI, gRPC o AsyncAPI.
  • Versionado — Los endpoints de la API deben incluir un prefijo de versión (/v1/, /v2/).
  • Documentación de autenticación — Los esquemas de seguridad deben estar documentados en el contrato.
  • Sin endpoints sin documentar — Los archivos de handlers sin su documentación de contrato correspondiente generan una infracción.

Security Baseline (8 reglas)

  • Uso obligatorio de gateway — El tráfico externo debe pasar por un API gateway o un balanceador de carga. Ningún servicio se expone directamente.
  • Gestión de secretos — Nada de secretos, claves API ni contraseñas escritos en el código fuente. Usa variables de entorno o un gestor de secretos.
  • Controles de acceso externo — Los servicios que aceptan peticiones externas deben exigir autenticación y limitar la tasa de peticiones.
  • TLS obligatorio — Toda la comunicación entre servicios debe usar TLS. Nada de HTTP en texto plano entre servicios.

Personalizar las reglas

Tras instalar un pack, cada regla es totalmente editable:

  • Cambiar la severidad — Baja una regla de critical a medium si no encaja con tu tolerancia al riesgo
  • Desactivar reglas concretas — Desactiva las reglas que no necesites sin quitar el pack entero
  • Modificar la configuración — Ajusta los globs de archivos, los patrones, los imports permitidos o las definiciones de capas para adaptarlos a la estructura de tu proyecto

Ve a Hub de Agentes y haz clic en el icono de edición de cualquier regla para modificarla.

Combinar packs

Los packs se suman. Instala varios packs para cubrir distintos aspectos de la arquitectura:

Combinación Caso de uso
Microservices + API-First + Security Baseline Plataforma de microservicios orientada a APIs con guardrails de seguridad
Clean Architecture + Security Baseline Monolito con límites estrictos entre capas y buena higiene de seguridad
Event-Driven + Microservices Sistema de microservicios con event sourcing
API-First + Clean Architecture Monolito o monolito modular guiado por contratos

Si dos packs contienen reglas que se solapan, Archyl las deduplica, sin conflictos.

Contribuir

Los packs de reglas son de código abierto. Puedes proponer packs nuevos, añadir reglas a los existentes o reportar incidencias:

Próximos pasos