Navegación Bilingüe: English · Español (este documento) Subir: Portal del Repositorio
Meta: traducir los requisitos de negocio aprobados en contratos técnicos inmutables antes de escribir código (BR-002), y alojar la suite de diseño de la aplicación Tracker.
Objetivos:
- Definir el modelo de dominio de Design (TechnicalBlueprint, Contract, ADR, DataSchema).
- Especificar los internos de la aplicación Tracker: backend NestJS, frontend React, diseño de datos PostgreSQL.
- Documentar el motor de gates, el motor de contingencias y las integraciones externas (UMS, Core).
Modelo de Dominio (DDD)
| Documento | Descripción | Propósito | Tipo |
|---|---|---|---|
| Modelo de Dominio Consolidado y E/R | El diseño DDD único y consolidado: modelo conceptual propuesto, los 9 bounded contexts, agregados, value objects y el diseño E/R de los 10 schemas | Fuente única del diseño de dominio propuesto — el detalle táctico por contexto se navega desde aquí | DDD |
Arquitectura de la Aplicación
| Documento | Descripción | Propósito | Tipo |
|---|---|---|---|
| Arquitectura Objetivo (TAD) | Arquitectura técnica maestra: bounded contexts, modelo de dominio, CQRS, capas, despliegue | Referencia única para entender cómo se construye toda la aplicación Tracker | Arquitectura |
| Diseño Backend NestJS | Blueprint del backend: módulos, buses CQRS, repositorios, guards, middleware | Guiar a los desarrolladores backend al implementar cualquier bounded context | Backend |
| Diseño Frontend React | Blueprint del frontend: shell Module Federation + 7 remotes, estado Zustand/TanStack, routing | Guiar a los desarrolladores frontend al construir o extender un microfrontend | Frontend |
| Diseño de Datos PostgreSQL | Diseño físico de datos: 10 schemas, DDL completo, políticas RLS, índices, control de concurrencia | Implementar o migrar la base de datos exactamente como fue aprobada | Datos |
Motores de Gates y Contingencias
| Documento | Descripción | Propósito | Tipo |
|---|---|---|---|
| Diseño de Phase Gate | Motor de evaluación de gates: modelo de criterios, checklists de requisitos, manejo de excepciones | Implementar cómo las compuertas evalúan, bloquean y autorizan transiciones de fase | Arquitectura |
| Diseño del Re-Do Flow | Motor de contingencias del Release: triggers, modelo de estados, algoritmo de recálculo, autorización humana | Implementar el recálculo automático de contingencias cuando un release se bloquea | Arquitectura |
Integraciones Externas
| Documento | Descripción | Propósito | Tipo |
|---|---|---|---|
| Integración de Autenticación UMS | Integración de identidad con UMS SaaS: validación JWT, rotación JWKS, guards de autenticación | Cablear la autenticación correctamente — el Tracker no gestiona usuarios | Integración |
| Diseño del Grafo de Autorización UMS | Traducción del grafo de autorización UMS a permisos del Tracker y jerarquía de roles | Implementar autorización fail-closed en toda superficie (Web/CLI/MCP) | Integración |
| Diseño de Integración con Core | Consumo de rulesets, esquemas de artefactos y taxonomía de Evolith Core, con estrategia de caching | Mantener al Tracker conforme con la línea base upstream inmutable (BR-005) | Integración |
| API de Asignación de Agentes | Contrato para asignar agentes al trabajo de fase: endpoints, modos, errores, eventos | Implementar la orquestación de agentes (manual/automated) con paridad REST/CLI/MCP (BR-008) |
API |
| Diseño de Artefactos y Evidencia | Diseño del sistema de artefactos: definiciones, instancias y registros de evidencia por compuerta | Implementar la cadena de evidencia que prueba cada decisión de gate | Arquitectura |
Planificación
| Documento | Descripción | Propósito | Tipo |
|---|---|---|---|
| Roadmap de Implementación | Plan de implementación: 8 fases, estimaciones de esfuerzo, dependencias, riesgos | Secuenciar el trabajo de construcción y rastrear el riesgo de entrega | Planificación |