--- title: "Arquitectura de software: lo que no se deshace" description: "Casi todo en un sistema se puede rehacer más adelante. Tres decisiones no: dónde vive el dato, qué límites hay entre las partes y cómo se cobra el dinero." canonical: https://caricalia.com/notas/arquitectura-tres-decisiones last-updated: 2026-09-08 --- # Arquitectura de software: lo que no se deshace > La arquitectura que importa son tres decisiones caras de deshacer. Con ejemplos de nuestra plataforma de facturación, donde una la fija la ley. Publicado: 2026-09-08 Autor: carlos Temas: arquitectura, datos, pagos --- ## Las tres decisiones que cuesta deshacer En un sistema de software casi todo se puede rehacer más tarde con dinero y paciencia. Se puede cambiar el lenguaje, el proveedor de servidores o la interfaz entera. Tres cosas no: dónde vive cada dato y quién es su dueño, qué límites separan las partes del sistema, y cómo se comporta la parte por la que entra el dinero cuando algo falla a medias. Lo que no se rehace sin parar el negocio es un modelo de datos con años de historial dentro y muchas integraciones leyéndolo. Por eso estas tres se hablan antes de escribir una línea de código. ## Uno: dónde vive el dato y quién es su dueño Cada dato necesita un único sitio donde se decide su valor. Los demás lo leen de ahí y no lo tocan. En cuanto un mismo hecho se guarda en dos sistemas que ambos pueden escribirlo, has creado un trabajo manual permanente para alguien. El caso típico: el CRM guarda el correo del cliente y la herramienta de facturación también, porque lo necesita para enviar el PDF. Se copian a mano cada día, y con el tiempo hay trabajo fijo de cuadrar dos listas sin ninguna regla que diga cuál manda cuando no coinciden. Elegir el dueño es la parte fácil. La que se olvida es el historial: si guardas solo el estado actual, has decidido sin querer que la pregunta «cómo estaba esto en marzo» no tenga respuesta. Y esa pregunta la hace una auditoría, un cliente que reclama o la propia empresa cuando quiere saber por qué un pedido acabó como acabó. Por eso, en la parte del sistema donde el pasado importa, se guarda lo que pasó y no solo cómo está ahora. En vez de sobreescribir un precio, se registra quién lo cambió, cuándo y de qué valor a cuál. ## Dos: qué límites hay entre las partes Un límite bien puesto se reconoce por una cosa: puedes cambiar lo que hay dentro sin avisar a nadie de fuera. Si para tocar el cálculo de descuentos hay que revisar seis sitios que también lo calculan, ahí no hay límite. La pregunta útil es qué cambio previsible te obliga a tocar más de una parte. Coge los tres cambios que sabes que vas a pedir el año que viene y mira cuántas piezas toca cada uno. Si cada cambio normal atraviesa medio sistema, el reparto está mal. El error caro es partir el sistema por tecnología en lugar de por responsabilidad. Separar «la base de datos», «la lógica» y «la interfaz» no ayuda, porque cualquier funcionalidad nueva las cruza las tres. Separar «facturación» de «catálogo» sí, porque casi ningún cambio de catálogo debería tocar cómo se emite una factura. El otro error es partir demasiado pronto. Cada límite que pones es una conversación que hay que mantener después: contratos, versiones, qué pasa cuando una parte está caída. Los límites hacia fuera merecen el mismo cuidado. Cuando integras un sistema de terceros, lo que llega por su [API](/glosario/api) o por un [webhook](/glosario/webhook) no debería entrar tal cual en tu modelo. Se traduce en el borde, en un solo sitio, para que el día que ese proveedor cambie su formato haya un solo sitio que tocar. ## Tres: cómo se comporta la parte que cobra En la parte por la que pasa dinero, la pregunta que ordena el diseño es qué ocurre cuando la operación falla por la mitad. Una operación de cobro toca varias cosas seguidas. Se apunta el pedido, se pide el cargo al banco, se emite la factura, se avisa al cliente. Cualquiera de esos pasos puede fallar sin decirte si se hizo o no: un tiempo de espera agotado no significa que el cargo no se haya hecho, solo que no has recibido la respuesta. De ahí salen tres propiedades que esa parte necesita tener desde el primer día, porque añadirlas después obliga a revisar todo lo que ya se cobró. **Repetir tiene que ser inofensivo.** Si el mismo intento de cobro llega dos veces, se cobra una. Se consigue haciendo que quien pide la operación mande un identificador propio, y que el sistema recuerde qué identificadores ya atendió y con qué resultado. En el oficio esto se llama idempotencia. **El registro de lo intentado vale tanto como el resultado.** Hay que poder reconstruir qué se pidió, cuándo, qué contestó el banco y qué hizo el sistema a continuación. Sin ese registro, una reclamación se acaba respondiendo devolviendo el dinero por si acaso. **Hace falta un camino de vuelta escrito.** Un pedido no puede quedarse cobrado y sin factura, ni facturado y sin cobrar. Cuando los pasos no caben en una sola operación atómica, se decide por adelantado cómo se deshace cada uno y quién lo dispara. ## Un ejemplo real: la numeración de las facturas En [BeeL](/casos/beel) operamos nuestra propia plataforma de facturación con Verifactu. La numeración obliga a resolver ahí las tres decisiones a la vez, y no deja margen de opinión porque la fija la ley. La numeración de una serie tiene que ser correlativa y sin huecos. Eso descarta la forma cómoda de generar números cuando hay varios procesos a la vez, que es dejar que cada uno coja el siguiente disponible: si dos emiten a la vez y uno falla después de haber cogido su número, queda un hueco que hay que explicar delante de la Agencia Tributaria. Así que el número se asigna dentro de la misma operación que deja la factura emitida, con la serie bloqueada mientras tanto, y cada factura queda encadenada a la anterior. Si algo falla en mitad del proceso, no hay número gastado. La decisión de datos va pegada: una factura emitida no se edita nunca. Se corrige con una rectificativa, que es un documento nuevo que apunta al anterior. El historial está en el propio modelo de datos. Y el límite hacia fuera existe porque el registro en la AEAT es un sistema ajeno, con sus propios tiempos y sus propias caídas. El envío vive en su borde, con reintentos que no duplican registros, para que una incidencia allí no impida seguir emitiendo. ## Cómo se toman estas decisiones sin adivinar Mirando dos cosas que el propio negocio ya sabe: qué preguntas va a tener que responder sobre el pasado, y qué cambios sabe que va a pedir en los próximos doce meses. La primera lista dice qué historial hay que guardar. La segunda, dónde poner los límites. Las dos caben en un folio y ninguna requiere saber programar. Las escribimos en la primera semana de [cada diagnóstico](/diagnostico), delante de quien va a firmar, y ahí es también donde se mira si alguna de las tres se decidió mal en un sistema que ya está en marcha. Cómo trabajamos está en [software a medida](/software-a-medida).