Essential Complexity
Qué permanece por el problema elegido
Essential Complexity describe la complejidad que surge de distinciones, reglas, interacciones y restricciones que el sistema realmente debe representar o satisfacer. Su alcance depende del problema elegido y de los resultados requeridos. La pregunta útil es: «¿esencial para qué problema y bajo qué condiciones?».
En Commerce, aceptar un pago no equivale siempre a capturarlo, devolverlo o conciliarlo. Si esas actividades están dentro del alcance, sus diferencias deben conservarse en alguna representación. Llamarlas a todas «procesar» puede reducir nombres y perder información necesaria para cumplir la promesa.
La complejidad esencial tampoco equivale al código de negocio existente. Una regla implementada puede haber caducado; una obligación de seguridad o disponibilidad puede seguir siendo necesaria aunque no aparezca en el cálculo comercial. Hace falta recuperar quién exige cada resultado, no clasificar por carpeta.
Brooks: origen y alcance histórico
En No Silver Bullet, Brooks distingue essential difficulties, relacionadas con construir las estructuras conceptuales del software, de accidental difficulties, asociadas a su representación e implementación. Examina complexity, conformity, changeability e invisibility como dificultades esenciales. Esa discusión es más amplia que una separación entre lógica comercial y plataforma. No Silver Bullet: Essence and Accidents of Software Engineering, informe original UNC de 1986, secciones 2 y 3.
Los términos Essential Complexity y accidental-complexity adaptan ese framing ampliamente usado a una pregunta arquitectónica contextual. Los ejemplos de Commerce y el modelo de razonamiento de este artículo son aplicaciones del Atlas; no afirmaciones de Brooks sobre tecnologías o perfiles actuales.
Moseley y Marks proponen después una definición deliberadamente más estricta, referida al problema de los usuarios en un mundo ideal. Su enfoque no coincide automáticamente con todo lo que resulta obligatorio en una implementación concreta. Out of the Tar Pit, sección 6. Declarar la perspectiva evita presentar estas fuentes como una taxonomía idéntica.
Domain complexity es una fuente posible
Las reglas del dominio pueden exigir distinciones difíciles: devolución parcial, autorización que vence, reserva de existencias o responsabilidad por una entrega. Pero también importan restricciones del mundo físico, concurrencia, interoperabilidad, obligaciones de seguridad, protección de personas y resultados requeridos ante fallos.
Un dispositivo que debe decidir sin conexión enfrenta condiciones diferentes de un formulario conectado permanentemente. Un sistema que debe seguir operando ante una caída regional necesita atender preocupaciones que la mera definición de Order no describe. La fuente de dificultad puede exceder el modelo comercial.
Esto tampoco vuelve esencial cualquier mecanismo de disponibilidad. Un resultado exigido necesita explicación; replicación, routing y recuperación son respuestas que deben compararse. Confundir la obligación con una respuesta específica impide investigar una alternativa que cumpla lo mismo con menos dificultad agregada.
Alcance: autorización o ciclo completo
Si Commerce solamente autoriza pagos, debe distinguir solicitudes admitidas, rechazadas e inciertas según el comportamiento acordado. Si también realiza capturas, reembolsos parciales, disputas y liquidación multimoneda, el problema incorpora nuevas obligaciones y estados relevantes.
Ese crecimiento puede justificar mayor complejidad sin demostrar peor arquitectura. La comparación correcta pregunta si las representaciones y mecanismos son adecuados para el alcance, no si el sistema más amplio tiene tantos nombres como el sistema inicial.
Una capacidad delegada tampoco desaparece del mundo. Si un proveedor gestiona conciliación, Commerce quizá solo necesite comprender su contrato y evidencia de cumplimiento. Cambia la responsabilidad asumida y la exposición local; permanecen interacciones que permiten sostener el resultado acordado.
Reformular cambia lo que es esencial
Essential no significa inmutable para siempre. Stakeholders pueden eliminar una capacidad, modificar una regla o aceptar una compensación distinta. architectural-drivers permite recuperar qué necesidades siguen justificando las decisiones y cuáles fueron supuestos no confirmados.
Por ejemplo, «comprobar stock global exacto antes de aceptar cada pedido» puede reconsiderarse como «aceptar un margen acordado de sobreventa con recuperación definida», si quienes tienen autoridad realmente admiten ese compromiso. El segundo problema permite alternativas diferentes.
No sería correcto afirmar que una arquitectura eliminó la coordinación manteniendo intacta la primera promesa. Cambió el problema o su condición de corrección. Hay que registrar el nuevo compromiso y sus efectos sobre clientes, Inventory y operación, además de simplificar el mecanismo.
También se puede simplificar una representación conservando el comportamiento. Eliminar estados redundantes derivados de otros hechos difiere de eliminar distinciones exigidas. La revisión necesita demostrar equivalencia relevante, en vez de asumir que menos variables significa igual información.
Estados que deben seguir distinguiéndose
Un Order puede estar Pending, Confirmed, Cancelled, Shipped o Returned. Si las acciones permitidas y obligaciones dependen de esos estados, alguna representación equivalente debe conservar la diferencia. No obliga a una clase, enum o state machine particular.
En Payments, Authorized, Captured, Refunded y PartiallyRefunded pueden producir comportamientos distintos. Un booleano Paid pierde información cuando captura y autorización permiten acciones diferentes o cuando interesa cuánto se devolvió. Una interface más breve no corrige esa pérdida.
Conviene distinguir el hecho requerido de caches, indicadores duplicados y estados intermedios introducidos por la solución. Guardar una proyección puede atender latencia; debe explicar actualización y reconstrucción. Ese trabajo no es idéntico a la necesidad de recordar el pago autorizado.
Drivers, constraints y mecanismos
Esta síntesis del Atlas separa tres preguntas para razonar, sin imponer una clasificación absoluta de cada línea de código:
| Plano de análisis | Pregunta en Commerce |
|---|---|
| Problema y comportamiento | ¿Qué distingue autorización de captura y devolución? |
| Drivers y restricciones | ¿Qué disponibilidad se exige y qué proveedor es obligatorio? |
| Mecanismo elegido | ¿Cómo representamos estados, confirmamos resultados y recuperamos fallos? |
Una constraint auténtica limita las opciones actuales. constraints ayuda a precisar origen, alcance y revisión. Un protocolo legacy puede ser obligatorio para el equipo e incidental respecto de la semántica comercial. Necesidad local y esencia del problema no son identidades universales.
Una necesidad de seguridad, interoperabilidad o disponibilidad puede justificar complejidad arquitectónica. quality-attributes-overview distingue resultados evaluables de respuestas propuestas. Inventar una exigencia de disponibilidad sin stakeholder tampoco demuestra que toda complejidad introducida para atenderla sea inevitable.
Distribución, autoridad y coordinación
Si el compromiso exige operación geográficamente independiente, hay que atender fallos e interacción entre ubicaciones. Si la distribución proviene únicamente de separar una herramienta interna sin un driver correspondiente, no toda dificultad de red pasa a ser esencial.
data-ownership permite examinar autoridad real. Payments no puede redefinir libremente existencias de Inventory. La obligación de respetar esa autoridad puede permanecer con llamadas locales o remotas; cómo se protege y representa admite decisiones diferentes.
Cuando un invariante requerido involucra autoridades independientes, existe una preocupación de coordination. La necesidad de mantenerlo se distingue de elegir 2PC, Saga o reconciliación manual. Cada respuesta ofrece compromisos que deben comprobarse frente a la promesa concreta.
decomposition y communication pueden cambiar dónde aparece ese trabajo. Separar unidades puede convertir una confirmación local en un protocolo entre participantes. El requisito original y las obligaciones adicionales del corte elegido deben analizarse por separado.
Ocultar, localizar y representar mejor
Una interface de autorización puede ocultar autenticación y protocolos privados del proveedor. Orders conoce menos detalles, mientras Payments y el proveedor siguen atendiendo estados, errores y compromisos. Ocultar a un consumidor es valioso sin ser eliminación global.
interfaces y modularity ayudan a limitar exposición y propagación. Un modelo coherente puede facilitar razonamiento sobre distinciones necesarias; el carácter esencial no justifica representaciones confusas, duplicación o accesos que obliguen a todos los consumidores a comprender cada excepción.
La frontera también necesita exponer lo suficiente. Si una autorización incierta se presenta como un rechazo definitivo para simplificar la API, el consumidor puede repetir una operación bajo una premisa incorrecta. El diseño debería conservar la diferencia que afecta la decisión siguiente.
Reducir dificultad para un equipo puede transferir trabajo a otro. systems-thinking invita a ampliar el análisis: quién sostiene la representación, quién responde ante una discrepancia y qué obligación queda escondida detrás de una llamada aparentemente sencilla.
Tamaño, dificultad y coupling
Complejidad y volumen se relacionan sin ser equivalentes. Una tabla repetitiva de mapeos puede ser extensa y fácil de comprender; un algoritmo breve de concurrencia puede exigir razonamiento delicado. LOC, servicios o clases no son una medida universal. architectural-significance examina consecuencias sistémicas: un algoritmo complejo que preserva todos los compromisos externos puede continuar siendo una decisión local de implementación.
Coupling puede amplificar propagación del cambio, pero no explica toda complejidad. Reglas necesarias pueden convivir dentro de un módulo cohesivo; reglas sencillas pueden repartirse entre dependencias enredadas. dependency-structure permite observar esas relaciones sin confundirlas con la esencia del problema.
Dificultad percibida también depende de experiencia, documentación y herramientas. Familiaridad puede facilitar comprensión sin alterar los compromisos que deben mantenerse. Las distinciones entre complex y complicated varían entre autores; este análisis no necesita convertirlas en una taxonomía obligatoria.
Simplificar sin borrar la promesa
technical-debt examina carga futura de una condición técnica; una regla necesaria de devolución no es deuda solo por ser difícil. En legacy-systems, esa distinción también protege conocimiento histórico: mejorar la representación exige conservar o cambiar deliberadamente la semántica, sin eliminarla bajo una etiqueta de modernización.
Investigar primero qué resultados y distinciones son necesarios; después, cómo representarlos con claridad y cuánto trabajo agrega cada mecanismo. modifiability y evolvability ayudan a evaluar si esa representación permite cambios y adaptación bajo escenarios reales.
No hay un premio por la arquitectura de apariencia más simple. Una solución que omite corrección, seguridad o recuperación requerida no cumple el problema. La heurística es sostener complejidad justificada por resultados necesarios y revisar la agregada por la solución.
Lo esencial puede modelarse mejor, esconderse de participantes que no necesitan conocerlo o cambiar al reformular el alcance. La honestidad consiste en distinguir esas intervenciones y verificar qué promesa se conserva, cuál se modifica y quién debe seguir cumpliéndola.