Diseño Impulsado por el Dominio (Principal Level)
Por Lex de SigmaStudioz.
Haz que la propiedad del negocio sea obvia a través de rutas, nombres, contratos y dependencias. Optimiza para un comportamiento correcto, cambios legibles, rendimiento medido y evolución económica. Aplica esta habilidad al cambio solicitado; no es una autorización para rediseñar el proyecto.
Ejecución automática
Aplica esta línea base antes de planificar o editar código de producción; no esperes una invocación de habilidad, fracción de activación o una solicitud de arquitectura. Lleva a cabo la implementación autorizada, la reutilización, la corrección de brechas, la verificación y los traspasos como parte de la tarea de codificación, en lugar de simplemente sugerirlos. Para tareas solo de revisión o solo de planificación, aplica el mismo razonamiento sin editar código. Mantén el trabajo proporcional al alcance y al riesgo; el uso automático no autoriza cambios no relacionados o delegación.
Portabilidad del agente y traspasos
Estas son instrucciones neutrales para los agentes que pueden leer Markdown e inspeccionar un proyecto. Usa las herramientas de búsqueda, compilación, prueba y ejecución disponibles; no se requiere un proveedor, plugin o CLI en particular. Respeta la jerarquía de instrucciones del anfitrión, los permisos y el alcance explícito de la tarea. Esta habilidad no habilita capacidades deshabilitadas ni otorga permiso para implementar, publicar o realizar cambios destructivos.
Cuando la delegación ya está autorizada, pasa la ruta accesible de la habilidad o las instrucciones relevantes, los archivos/módulos propios, las condiciones de aceptación y las obligaciones de seguimiento en la asignación. No asumas que un agente hijo hereda la conversación del padre, las habilidades cargadas o los archivos de instrucciones globales. Exige evidencia y bordes no resueltos de cada trabajador; concilia los seguimientos a través de los límites de los trabajadores. Delega invariantes verificados; etiqueta los algoritmos propuestos como suposiciones y desafía las contradicciones. Si el hijo no puede leer la habilidad, proporciona su contenido relevante dentro del contexto permitido. No generes agentes solo porque esta sección describe traspasos. Antes de adoptar otro flujo de trabajo, registra el número de compañeros de equipo y roles autorizados por el usuario. Cada agente de exploración, implementación y revisión consume ese presupuesto; las revisiones de seguimiento permanecen en el coordinador cuando se agota. Las habilidades de flujo de trabajo opcionales no pueden expandir el límite del usuario. Trata los resúmenes de tareas y el pseudocódigo como propuestas: verifica independientemente sus algoritmos contra el contrato original. Corrige un plan defectuoso en lugar de conservarlo como un requisito de implementación.
Contrato de traspaso
Cada asignación de agente autorizada o traspaso reanudable debe identificar:
| Campo | Contexto requerido |
|---|---|
| Meta y límites | Resultado del usuario, criterios de aceptación, acciones autorizadas, exclusiones |
| Ubicación | Raíz del espacio de trabajo accesible, rama/árbol de trabajo o revisión real, rutas de instrucciones/habilidades relevantes |
| Propiedad | Archivos/módulos exactos que posee el agente; otros propietarios activos y dependencias de interfaz compartida |
| Arquitectura | Propietario del dominio, puntos de entrada/contratos públicos, rutas importantes de llamantes y consumidores |
| Estado actual | Trabajo implementado versus pendiente, ediciones locales, decisiones y por qué, fallos conocidos |
| Evidencia | Comandos y resultados, ruta/ID del libro de seguimiento, revisión verificada, entornos no disponibles |
| Próxima acción | Próximo paso concreto, bloqueadores, entradas requeridas y formato de retorno esperado |
Los anfitriones pueden hacer cumplir este contrato con el guardián de delegación.
El guardián opcional de Claude proporciona esta línea base y verifica los límites numéricos explícitos de agentes en el
historial nativo de turnos del usuario (Usa N compañeros/agentes/trabajadores); la falta de historial deja la aplicación en manos del
coordinador. No otorga herramientas ni garantiza la corrección semántica.
Cuando ese guardián esté instalado, antepone la asignación con HANDOFF_JSON= y un objeto JSON que contenga
goal, limits, workspace, revision, owns, interfaces, state, evidence, next, return,
trace, checks y baseline. return debe ser un objeto con instrucciones no vacías paths, contracts,
checks, gaps y remaining. trace nombra rutas y casos de fallo a seguir;
checks nombra las comprobaciones a ejecutar o por qué no están disponibles. baseline es la ruta accesible de esta habilidad. Esto se aplica
también a las asignaciones de exploración y revisión. Una asignación rechazada debe corregirse antes de reintentar.
Usa rutas reales en el anfitrión del agente receptor; incluye el contenido necesario cuando las rutas difieran o sean inaccesibles. Proporciona a los comandos su directorio de trabajo y los nombres de configuración no secreta requeridos. Nunca coloques credenciales o cargas de trabajo de ejecución privadas en las notas de traspaso. Un nombre de rama por sí solo no es prueba de que un hijo vea trabajo no comprometido; establece si el checkout es compartido o aislado.
Para trabajo concurrente, acuerda contratos públicos y propiedad de archivos antes de cambios superpuestos. Diles a los agentes que no están solos: preserva las ediciones de otros y coordina los archivos compartidos a través del propietario asignado. Rebase o concilia los cambios aislados antes de reclamar integración; no descartes silenciosamente el trabajo. Al regresar, informa las rutas modificadas, los cambios en los contratos públicos, las comprobaciones con resultados, los ID/estado de brechas y las acciones restantes. El coordinador reconcilia el libro de seguimiento y verifica las costuras entre agentes y los consumidores afectados; varias comprobaciones de trabajadores exitosas no establecen un flujo de trabajo integrado funcional.
Por interrupción o pérdida de contexto, guarda el traspaso en el registro de tarea/seguimiento existente con una marca de tiempo y revisión de contenido, luego enlaza ese registro. Al reanudar, inspecciona el checkout y el diff actual antes de actuar; revalida las suposiciones obsoletas. No crees una segunda fuente de verdad para la tarea.
La instalación local no implica instalación en la nube, en un anfitrión remoto o en un agente no relacionado. Establece el descubrimiento en cada anfitrión de ejecución; usa una instrucción global nativa del anfitrión para enrutar el trabajo relevante aquí. Si el descubrimiento o el acceso a archivos no está disponible, informa ese límite en lugar de reclamar una aplicación global.
Contrato de ingeniería principal
- Comienza con las capacidades del negocio, invariantes, flujos de trabajo de usuario y restricciones operativas.
- Prefiere alta cohesión dentro de los dominios y bajo acoplamiento entre ellos.
- Coloca el código específico del dominio con su propietario; agrupa el código por función dentro de ese límite.
- Dale a cada regla de negocio y modelo de escritura autoritativo un propietario claro.
- Reutiliza las implementaciones existentes antes de agregar otra; evita duplicar el conocimiento del negocio.
- Elige la arquitectura más pequeña que satisfaga las necesidades demostradas y admita cambios probables.
- Separa observaciones, suposiciones, decisiones y evidencia. No inventes requisitos o puntos de referencia.
- Preserva el comportamiento público funcional durante cambios estructurales a menos que se solicite un cambio de comportamiento.
- Mejora la ruta tocada y sus dependencias necesarias. No arrastres código no relacionado a la tarea.
1. Establece el contexto antes de editar
Inspecciona las instrucciones aplicables del repositorio, manifiestos, exportaciones de paquetes, puntos de entrada, módulos de dominio existentes, migraciones, pruebas y evidencia de ejecución relevante. Busca comportamiento equivalente y paquetes compartidos existentes antes de crear archivos. Usa el lenguaje y las herramientas del repositorio.
Traza un flujo de trabajo relevante desde la entrada del usuario o evento hasta la autorización, el servicio, las reglas del dominio, la persistencia, los efectos posteriores y el estado devuelto o mostrado. Incluye rutas de error. Identifica consumidores y escritores reales; un nombre de directorio por sí solo no establece la propiedad.
Para trabajos de arquitectura sustanciales, establece un marco de decisión compacto:
| Pregunta | Respuesta requerida |
|---|---|
| Resultado del negocio | ¿Qué flujo de trabajo de usuario o invariante cambia? |
| Propiedad | ¿Qué contexto acotado posee el significado y las escrituras autoritativas? |
| Consumidores | ¿Qué aplicaciones, trabajos, módulos o sistemas externos necesitan la capacidad? |
| Restricciones | ¿Compatibilidad, volumen de datos, latencia, tenencia, disponibilidad, costo, implementación? |
| Evidencia actual | ¿Rutas relevantes, contratos, fallos, tiempos o comportamiento de consultas? |
| Cambio más pequeño | ¿Qué se puede reutilizar y qué límite realmente necesita cambiar? |
| Finalización | ¿Condiciones de aceptación observables y verificación apropiada? |
Pregunta solo cuando una decisión empresarial no resuelta bloquea el trabajo correcto; de lo contrario, expresa suposiciones.
2. Define los límites del dominio
Un contexto acotado posee un vocabulario, reglas y modelo de negocio coherentes. Una característica, tabla,
pantalla, capa de framework, despliegue o nombre de equipo no es automáticamente un contexto acotado.
Usa nombres de capacidad empresarial como billing, scheduling, playback o execution.
- Separa los contextos cuando el mismo término tiene diferentes significados, invariantes, ciclos de vida o propietarios.
- Mantén las entidades juntas cuando su invariante deba cumplirse en una operación atómica.
- Evita agregados sobredimensionados: distingue los verdaderos invariantes atómicos de los flujos de trabajo entre contextos que necesitan consistencia explícita, orquestación o compensación en lugar de una transacción compartida.
- Distingue la diferenciación central del negocio de las capacidades de soporte y commodity.
- Invierte esfuerzo de modelado donde la complejidad o el valor del negocio lo justifiquen; mantén simple el CRUD simple.
- Registra la propiedad ascendente/descendente y la traducción en límites importantes del contexto.
- Consume otro contexto a través de su API pública, puerto o contrato; no importes sus internos.
- Traduce los modelos externos/proveedores en el límite en lugar de filtrarlos en las reglas de negocio.
- Prefiere un monolito modular hasta que la implementación independiente, el escalado, el aislamiento de fallos o la propiedad justifiquen una división en servicios. Un monorepo no implica microservicios.
Si un cambio abarca dominios, identifica el caso de uso orquestador y la responsabilidad de cada dominio. Coloca la orquestación con el propietario del flujo de trabajo, no en un ayudante global o componente de UI.
3. Estructura por dominio, luego por función
Elige primero el ámbito propietario, luego la categoría funcional. Dentro de ese ámbito:
| Categoría | Responsabilidad |
|---|---|
model/ | Entidades, objetos valor, invariantes, políticas, eventos de dominio |
services/ | Casos de uso de aplicación nombrados y orquestación |
ports/ | Interfaces para persistencia, relojes, identidad, colas, proveedores |
adapters/ | Implementaciones concretas de base de datos, transporte, proveedor o plataforma |
contracts/ | DTOs públicos, esquemas de eventos, validación, contratos de compatibilidad |
components/, hooks/ | UI de dominio y comportamiento de UI cuando ese dominio posee un frontend |
shared/ | Código reutilizable para consumidores dentro de ese ámbito |
tests/ o pruebas colocalizadas | Verificación de comportamiento y límites usando las convenciones del repositorio |
Las implementaciones de servicios pertenecen a services/ en su capa propietaria. Cuando se necesita un servicio de dominio
para una regla que abarca entidades, colócalo en model/services/; la orquestación se queda en el
services/ principal del dominio. Los servicios de proveedor pueden vivir en adapters/services/ cuando sea útil.
Para una aplicación, usa src/domains/<domain>/{model,services,ports,adapters,contracts,shared} según
sea necesario, un punto de entrada público, rutas de framework ligeras y una raíz de composición. Coloca elementos primitivos
neutrales al dominio bajo src/shared/. Crea solo directorios que contengan código real.
Ejemplo de monorepo; respeta las convenciones de paquetes existentes y las exportaciones explícitas:
apps/
web/ # Composición y presentación de la aplicación
api/ # Puntos de entrada de transporte ligeros
worker/ # Registro y composición de trabajos
packages/
billing/ # Paquete de espacio de trabajo propio
package.json # Exportaciones públicas y compatibilidad de ejecución
src/
services/ # Casos de uso compartidos por API/worker
shared/ # Reutilización local de facturación
index.ts # Fachada pública explícita
shared/
contracts/ # Paquete de espacio de trabajo neutral al dominio
ui/ # Consumidores de frontend compatibles
Registra paquetes reales en el espacio de trabajo; las rutas por sí solas no los hacen importables. En espacios de trabajo políglotas, expone bibliotecas compatibles o clientes generados a partir de esquemas canónicos; no intentes importar código a través de entornos de ejecución incompatibles.
Reglas de colocación
- Un consumidor y significado específico del dominio: mantenlo en ese dominio.
- Varios consumidores dentro de un dominio: usa
services/oshared/de ese dominio. - Varias aplicaciones compatibles necesitan código de dominio reutilizable: colócalo en un paquete de dominio del espacio de trabajo; el comportamiento privilegiado del servidor permanece del lado del servidor detrás de una API autorizada o contrato de cliente.
- Varios dominios necesitan el mismo primitivo neutral al dominio: usa código
shared/con ámbito. - Los consumidores necesitan diferentes significados de negocio: mantén modelos separados y traduce explícitamente.
- Flujo de trabajo entre dominios: usa un servicio de aplicación propietario y contratos de dominio públicos.
- Rutas, pantallas, controladores y trabajos: delega reglas a servicios; mantén las preocupaciones de transporte locales.
Nunca copies una capacidad en varias aplicaciones solo para que las importaciones sean convenientes. Nunca hagas de una aplicación la biblioteca de otra aplicación. Mueve la propiedad reutilizable hacia abajo a un paquete del que ambas puedan depender. Mantén los directorios requeridos por el framework; enrútalos a la estructura de dominio en lugar de luchar contra el framework. Respeta el empaquetado estándar del lenguaje y la arquitectura existente válida.
4. Aplica la dirección de dependencia
puntos de entrada -> servicios de aplicación públicos -> modelo + puertos
adaptadores -> puertos + modelo
bootstrap -> servicios + adaptadores # Conecta implementaciones concretas
paquetes de dominio -> paquetes compartidos neutrales al dominio
- El modelo no depende de HTTP, frameworks de UI, bases de datos, colas o SDKs de proveedores.
- Los servicios orquestan casos de uso a través de dependencias explícitas; los adaptadores implementan puertos.
- Los paquetes compartidos no importan aplicaciones o internos de dominio. Evita las dependencias circulares.
- Las llamadas entre dominios usan contratos públicos; evita los ciclos de llamada síncronas y las cadenas de uso intensivo.
- Exporta puntos de entrada intencionales. Bloquea las importaciones profundas con paquetes, linters o herramientas de compilación existentes.
- Divide los contratos seguros para navegador de las implementaciones solo para servidor y las dependencias privilegiadas.
- Mantén los SDKs privilegiados, clientes de base de datos, secretos y código del sistema de archivos fuera de los gráficos de dependencia del cliente.
- Los SDKs de proveedores pueden ejecutarse...