Árbol de decisión

Una regla de arquitectura que no ayuda a tomar decisiones termina siendo una frase decorativa. Este árbol existe para responder una duda concreta: ¿esta operación contiene una decisión del negocio o solo ejecuta una tarea técnica?

¿Alguien del negocio preguntaría por esto?
        │
       sí  →  api → flow (consulta fx/db y aplica reglas)
                    → api guarda mediante fx/db si hay cambios
        │
       no  →  api → fx

Y, si después de escribir hay que hablar con otro sistema, eso se queda en api/ o en api/actions/.

Operación	Camino	Por qué
Ver el carrito	`api` → `fx/db`	Lectura sin regla
Listar productos activos	`api` → `fx/db`	Filtro técnico
Agregar producto	API → flow → API → `fx/db`	El flow comprueba stock y cantidad; API guarda el carrito
Aplicar un cupón	API → flow → API → `fx/db`	El flow aplica la promoción; API guarda el resultado
Checkout	API → flow → API → `fx/db`, luego acciones	El flow arma el pedido; API lo guarda y coordina cobro y aviso
Tocar `updated_at`	`api` → `fx/db`	Campo técnico

¿Solo lectura?
    sí → ¿hay filtro de negocio o permiso?
            sí → flow
            no → fx directo
    no → ¿hay validación o regla?
            sí → flow
            no → fx directo

Esto es arquitectura adaptativa. El árbol sirve para no crear un flow vacío y, al mismo tiempo, para no esconder una regla dentro del handler. No se trata de escoger el camino más corto, sino el lugar que permite entender mejor la operación.

En las operaciones con cambios, el flow puede consultar fx/db, pero no escribe. API recibe su resultado y ejecuta la escritura, manteniendo la misma transacción cuando la regla lo requiere.