Usar código en las fronteras de orquestación
Mantener declarativas las reglas locales y transparentes; llevar la orquestación con estado y entre sistemas detrás de fronteras de servicio probadas.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01Contexto
Un proceso comercial de varios pasos combina aprobaciones, llamadas a API externas, trabajo reintentable y automatización visible para el usuario.
02Factores de decisión
- F01
Testabilidad
- F02
Aislamiento de fallos
- F03
Responsabilidad sobre el cambio
- F04
Fronteras transaccionales
03Opciones consideradas
Solo declarativo
Reglas locales y deterministas sobre registros
Coste: Fallos opacos a escalaSolo código a medida
Máquinas de estado complejas
Coste: Mayor esfuerzo de entregaHíbrido deliberado
Responsabilidades claras y acotadas
Coste: Requiere gobierno04Decisión
Usar automatización declarativa para reglas locales e inspeccionables. Invocar una frontera de orquestación en código para el estado entre sistemas, la idempotencia, los reintentos y la compensación.
05Consecuencias
- La responsabilidad se define por frontera, no por preferencia del desarrollador.
- Las automatizaciones no pueden encadenar directamente efectos externos no gestionados.
- El servicio publica estados observables de vuelta en el flujo del usuario.
06Cuándo revisarla
El proceso pasa a ser local y determinista.
La orquestación nativa de la plataforma ofrece controles equivalentes de pruebas y recuperación.
07Dónde se aplica esta decisión
Casos que adoptan esta decisión, y por qué importa en cada uno.
- Caso de procesos / 02Diseñar un proceso de oferta a pedido con responsabilidades clarasVincular las aprobaciones a versiones de oferta, adelantar la validación del ERP y dar un responsable a los pedidos rechazados.
- Caso de procesos / 04Diseñar el proceso de entrada de RFQ antes de introducir IADefinir el proceso de entrada de RFQ —definiciones, responsables, validación— antes de que un agente de IA ejecute cualquier parte.
- Caso de datos / 03Devolver señales analíticas al CRM operativoUn contrato de writeback para KPI y segmentos derivados: a nivel de cuenta, de solo lectura en el CRM, con sello de frescura y versión, conciliado con lo publicado y convertido en exactamente una tarea por señal.
- Caso de automatización / 01Un orquestador mensual para el rendimiento comercialUn registro de ejecución por periodo con máquina de estados, guardas de arranque único, continuaciones por lote y una conciliación antes del cierre: un fallo en el paso cuatro se reanuda en el paso cuatro.
- Caso de automatización / 03Registrar visitas de forma guiada sin ocultar el procesoUn asistente de creación que rellena el contexto, pide solo lo que requiere criterio, valida las relaciones y crea la visita y su seguimiento como una única acción reanudable.
- Caso de modelo operativo / 05Gobernar los cambios del modelo operativo después del go-liveEl modelo operativo como producto: peticiones de cambio clasificadas por dominio, decididas por responsables con nombre, con evidencia y plazos, y publicadas en versiones—para que el modelo siga mejorando cuando el proyecto termina.
- Caso de adopción / 06Mantener la adopción con responsable cuando el equipo de proyecto se vaUn despliegue que terminó en el go-live: responsabilidades traspasadas de los roles de proyecto a responsables operativos con nombre, un registro de fricción que alimenta un único backlog gobernado, una cadencia de releases y señales de adopción revisadas con calendario, para que el diseño siga mejorando.