Constraints
Qué restringe las alternativas
Una constraint es una condición que limita o fija parte del espacio de decisiones permitido en un contexto arquitectónico. No expresa solamente algo deseable: descarta alternativas, exige una condición o impone un compromiso que el equipo actual no puede ignorar. Su alcance y autoridad importan tanto como su formulación.
En Commerce, procesar pagos es una necesidad. Usar el proveedor de pagos contratado obligatoriamente por la organización restringe cómo atenderla. Payments todavía necesita decidir cómo integrar ese proveedor, representar resultados y recuperar operaciones inciertas. La restricción reduce posibilidades sin describir toda la arquitectura.
El SEI presenta constraints como elecciones forzadas por factores externos dentro de las entradas de Attribute-Driven Design. Aquí distinguimos la condición impuesta de la decisión que toma el equipo dentro de ese margen. Es una ayuda de razonamiento compatible con que otro método llame a ambas decisiones. SEI: Attribute-Driven Design Method Collection.
Constraint y requirement
Una requirement expresa una necesidad o compromiso del sistema y sus stakeholders. Una constraint destaca el efecto de restringir soluciones. Las categorías pueden superponerse: un proceso de requirements puede registrar una plataforma obligatoria como requirement, y analizarla después como constraint arquitectónica.
No hay una oposición universal entre ambas palabras. arc42 incluye entre las constraints los requirements que limitan la libertad de diseño, implementación o proceso, y reconoce que algunas condiciones son negociables. Esa formulación ayuda a preguntar dónde existe libertad real, sin imponer una clasificación única para toda organización. arc42: Architecture Constraints.
En nuestro ejemplo, «permitir que una persona pague un pedido» admite múltiples realizaciones. «La autorización debe pasar por el proveedor contractual vigente» elimina algunas. La segunda puede seguir siendo una requirement en el registro del proyecto. Separar su papel en la conversación arquitectónica evita confundir resultado esperado con mecanismo obligatorio.
También conviene precisar qué está restringido. El contrato puede obligar a usar al proveedor para autorizar y permitir otro mecanismo para conciliación. Extenderlo a toda actividad financiera sin revisar su texto inventaría una limitación que el stakeholder no pidió.
Quality attributes y drivers
Una búsqueda que debe responder dentro de la latencia acordada en el 95 % de los casos se evalúa mediante un escenario con carga, entorno y medida definidos. quality-attributes-overview organiza esas propiedades y compromisos. La frase no selecciona por sí sola una región, lenguaje o motor de búsqueda.
«Ejecutar únicamente en la región soberana aprobada» restringe alternativas de ubicación. Puede haberse impuesto para atender security, cumplimiento regulatorio, costos u operabilidad. El motivo explica la condición; no convierte toda elección orientada a security en constraint ni todo objetivo de costo en una tecnología obligatoria.
architectural-drivers selecciona influencias que pesan en decisiones relevantes. Una constraint puede ser un driver; no todos los drivers son constraints, y una regla administrativa menor puede carecer de significancia para la decisión actual. La pregunta es qué opciones elimina y qué consecuencias introduce.
Constraint, decision, assumption y preference
Una constraint limita lo que puede elegirse; una decisión selecciona una alternativa entre las disponibles. Para el equipo que diseña una nueva capacidad, «Oracle no puede reemplazarse este año» puede ser una condición impuesta. Acceder mediante un adaptador que preserve autoridad de Payments es una decisión todavía discutible.
La misma elección puede cambiar de papel según el contexto. Una decisión de plataforma tomada por otro grupo constituye una constraint para este equipo si no tiene autoridad para revisarla. Registrar quién decide evita presentar como ley natural una elección organizacional.
Una assumption describe algo que damos por cierto para razonar y que necesita evidencia: «el proveedor nunca duplicará notificaciones» no impide elegir, sino que condiciona nuestras conclusiones. Si es falsa, el diseño puede fallar. Una preference expresa inclinación: conocer bien un lenguaje es relevante, pero no prueba que cualquier alternativa esté prohibida.
«Debemos usar microservices» puede ser una directiva formal, una decisión previamente aceptada, una preferencia o un hábito repetido sin fundamento. Antes de clasificarla, preguntar quién la exige, para qué sistemas, con qué excepciones y qué ocurriría si se cuestiona. La etiqueta no sustituye esas respuestas.
De dónde aparecen las restricciones
No hace falta una taxonomía exhaustiva. Algunas condiciones proceden de regulación o contratos; otras, de estándares internos, licencias, presupuesto, fechas, hardware o sistemas existentes. La disponibilidad de habilidades también puede limitar opciones que el equipo puede operar responsablemente.
Un dispositivo sin conectividad continua restringe colaboraciones remotas. Un plazo de transición puede impedir reemplazar una base existente sin prohibir encapsular su acceso. Una licencia puede limitar réplicas permitidas. Un mandato de proveedor puede afectar servicios disponibles sin obligar a adoptar todas sus herramientas.
La formulación necesita suficiente precisión para comprobarla. «Hay poco presupuesto» sirve como alerta, pero no permite comparar alternativas sin un horizonte y una magnitud acordados. «No introducir un nuevo servicio operativo durante esta entrega» restringe una decisión concreta y puede revisarse al cambiar la capacidad del equipo.
Hard, soft y posibilidad de revisión
Una hard constraint no puede violarse dentro del contexto de decisión actual. No significa necesariamente que sea inmutable para siempre. Una regulación puede cambiar; un contrato puede renegociarse; otra autoridad puede aprobar una excepción.
Soft constraint y preference tienen usos variables. Para el Atlas, conviene explicitar si una condición es negociable, quién puede negociarla y qué costo tendría hacerlo. El objetivo no es convertir los términos en una escala universal, sino conocer consecuencias reales de desafiar la condición.
Preguntar «¿qué pasa si no la cumplimos?» puede revelar una prohibición legal, una necesidad de aprobación, una penalidad económica o solamente incomodidad. No corresponde ignorar una condición porque parezca inconveniente. Tampoco aceptar indefinidamente una suposición histórica cuando ya existe capacidad de revisarla.
Commerce y las dimensiones que siguen abiertas
Mantener la base de datos existente durante este año restringe la transición. No determina quién tiene autoridad sobre cada tabla, qué puede desplegarse independientemente ni qué fallos quedan contenidos. Las implicaciones deben examinarse, sin atribuir a la restricción respuestas que no contiene.
| Dimensión | Pregunta que permanece abierta |
|---|---|
| data-ownership | ¿Payments conserva autoridad aunque comparta servidor de datos? |
| deployment | ¿Qué unidades pueden cambiar sin reemplazar la plataforma existente? |
| isolation | ¿Qué recursos y fallos siguen siendo comunes? |
| scaling | ¿Qué capacidad puede ampliarse dentro de los límites existentes? |
| portability | ¿Qué dependencias dificultan una transición posterior? |
Una obligación de desplegar en un solo appliance afecta Deployment, Isolation y Scaling. Puede admitir varios procesos, límites internos y responsabilidades separadas. Tampoco obliga a usar llamadas locales para toda integración externa.
architecture-decision-axes organiza esas preguntas. architecture-profile reúne paquetes de respuestas, pero una condición aislada no elige automáticamente un perfil completo. Conviene comparar variantes que respeten la restricción y, cuando exista autoridad, el costo de cambiarla.
Descubrir, documentar y revisar
serverless-architecture aporta un ejemplo de constraints explícitas del entorno: duración, runtimes, payload, red y cuotas pueden limitar alternativas. Delegar infraestructura exige aceptar y verificar esos contratos; hay que distinguir límites revisables de propiedades que obligan a cambiar la realización.
El trabajo arquitectónico incluye recuperar restricciones de contratos, operación y decisiones anteriores, además de discutir lo que los participantes dicen necesitar. Consultar al responsable de pagos puede revelar que el proveedor es obligatorio solo hasta una fecha; consultar al operador puede descubrir que una propuesta requiere capacidad inexistente.
Una nota útil conserva formulación, origen, alcance, responsable, consecuencia y condición de revisión. No exige inventar un proceso ni metadata nueva en cada documento del Atlas. En una decisión concreta, esos datos permiten entender por qué se descartó una opción y cuándo merece reconsiderarse.
Si dos constraints impiden satisfacer un compromiso importante, el diseño no debe ocultar el conflicto. Puede requerir cambiar alcance, negociar una condición o admitir un riesgo. Elegir una tecnología no resuelve por sí solo una incompatibilidad de obligaciones.
requirements-to-architecture separa una exigencia real de preferencia, estado actual y supuesto al interpretar el problema. design-process usa ese espacio de elección para contrastar propuestas: un proveedor SOAP obligatorio limita una integración, pero no decide todas las fronteras ni el profile de Commerce.
Errores frecuentes y uso
No toda petición es una constraint; una preferencia tecnológica tampoco se vuelve obligatoria por repetición. legacy-systems examina herencia que condiciona evolución, sin definirse por edad ni implicar inmutabilidad. Una restricción auténtica merece atención y puede tener una vía legítima de revisión. essential-complexity pregunta qué requiere el problema considerado; accidental-complexity distingue esa perspectiva del trabajo necesario para respetar, por ejemplo, un protocolo contractual vigente. Necesidad local no equivale automáticamente a esencia del problema comercial.
Usar este concepto cuando una discusión parece cerrada antes de comparar alternativas. Aclarar lo impuesto, lo elegido y lo supuesto permite concentrar esfuerzo en decisiones disponibles. El resultado buscado es un espacio de elección explicable, con límites verificables y condiciones de revisión.