Design Process

Diseñar como razonamiento revisable

Design Process es, en el Atlas, la práctica iterativa de pasar de objetivos, requisitos, restricciones e incertidumbre a decisiones y representaciones arquitectónicas evaluables frente a drivers relevantes. Su producto no es solamente un diagrama: incluye compromisos, razones, evidencia y preguntas todavía abiertas para poder construir y revisar una solución.

software-architecture aporta el objeto del razonamiento; architectural-significance ayuda a distribuir atención. El esfuerzo depende de consecuencias, riesgo y costo de cambio, no del número de cajas dibujadas. Un sistema pequeño también puede tener decisiones importantes sobre autoridad, acceso o recuperación. System Design no presupone millones de usuarios ni distribución entre servicios.

Esta práctica no prescribe una metodología única. requirements-to-architecture se concentra en interpretar necesidades y extraer influencias significativas; Design Process utiliza esas entradas para explorar, evaluar y refinar propuestas. Los canónicos existentes conservan sus definiciones: aquí interesa cómo combinarlos en una decisión situada.

Métodos que orientan sin convertirse en definición universal

El SEI presenta ADD como un método basado en requisitos arquitectónicamente significativos, incluyendo funcionalidad, atributos de calidad y restricciones. Presentación de ADD, 2018. Su versión 2.0 desarrolla un ciclo recursivo de diseño y comprobación; también admite requisitos incompletos y decisiones tentativas revisables. ADD 2.0, secciones 2 y 4.

ADD es una referencia concreta, no el significado de todo Design Process. ATAM aborda evaluación arquitectónica; no es otro nombre para ADD. utility-trees puede apoyar priorización y análisis en su contexto, sin convertirse en el proceso entero ni exigir realizar ATAM en cada cambio.

Como lectura de conjunto, Bass, Clements y Kazman separan requisitos significativos, diseño, evaluación y documentación en los capítulos 19–22 de Software Architecture in Practice, cuarta edición. Esa organización bibliográfica permite profundizar sin atribuir a una única actividad todo el trabajo arquitectónico.

Delimitar el problema y recuperar el contexto

Comenzar aclarando qué se diseña: producto, subsistema, integración, migración o capacidad. boundaries permite discutir actores, entorno y autoridad sin convertir el límite dibujado en separación física obligatoria. interfaces ayuda a localizar los compromisos con consumidores y proveedores que el diseño debe conservar o modificar deliberadamente.

Las entradas incluyen objetivos de negocio, funcionalidad, quality-attributes-overview, constraints, comportamiento existente, operación, organización, costo y obligaciones aplicables. No necesitan llegar completas ni ser independientes: un objetivo de abrir un mercado puede introducir necesidades de integración, soporte y residencia de datos.

En brownfield, legacy-systems y migration-strategy obligan a examinar lo que funciona, sus consumidores, datos y estados de transición. Greenfield reduce ciertas herencias, pero conserva límites comerciales, organizacionales y contractuales. Diseñar sobre una página vacía no hace que desaparezca el entorno donde habrá que operar.

Seleccionar preguntas que merecen una decisión

architectural-drivers guía el esfuerzo. No todos los requisitos tienen el mismo efecto sobre estructuras o compromisos. Actualizar una imagen de perfil puede caber en una capacidad existente; cargas de imágenes muy distintas, procesamiento exigido o residencia obligatoria pueden cambiar la atención necesaria. La función sigue importando en ambos casos.

Refinar preocupaciones vagas mediante quality-attribute-scenarios permite distinguir candidatos. «Rápido» deja abierta la frontera, carga y respuesta requerida. El escenario útil necesita describir la situación que discrimina alternativas y qué observación sería aceptable, sin inventar cifras para parecer preciso ni repetir aquí su modelo completo.

Una constraint supuestamente fija necesita origen, alcance y autoridad de revisión. «Nos gusta PostgreSQL», «lo usamos hoy» y «un contrato exige este engine» no tienen las mismas consecuencias. El proceso puede cuestionar la primera interpretación sin ignorar una obligación auténtica ni prometer libertad inexistente.

Mantener visible la incertidumbre

Una assumption es una creencia provisional del razonamiento, no un requisito validado. Usuarios simultáneos, distribución de tráfico y comportamiento de un partner pueden ser estimaciones. Un unknown señala información importante aún ausente: límite de conexiones, pico real, consumidores históricos o semántica de confirmación.

Registrar qué decisión depende de cada supuesto permite priorizar evidencia. Si un diseño solo es viable mientras un proveedor responda siempre dentro del presupuesto disponible, hay una incertidumbre relevante que investigar. Riesgo combina consecuencias y exposición según el contexto; no exige abrir una disciplina completa de gestión de riesgos en cada propuesta.

La profundidad debe seguir esas preguntas. Una decisión reversible y encapsulada puede justificarse con un análisis breve; cambiar un contrato público o autoridad de datos necesita otra confianza. No hay que eliminar toda incertidumbre antes de implementar, pero sí entender qué podría invalidar el próximo compromiso y quién acepta avanzar.

Examinar candidatos mediante Decision Axes

architecture-decision-axes organiza una revisión analítica, sin imponer el orden de diseño. En Commerce, estas preguntas conectan drivers con compromisos que conviene hacer visibles:

Eje	Pregunta situada para una propuesta
decomposition	¿Qué responsabilidades de Orders, Payments, Inventory y Shipping necesita reconocer esta solución?
dependency-structure	¿Qué cambios del proveedor de pagos deberían propagarse hacia Orders?
communication	¿Qué resultado espera cada interacción y qué ocurre si no llega?
coordination	¿Quién conduce confirmación, reserva y tratamiento de resultados incompletos?
data-ownership	¿Quién declara válido un estado de pago y quién puede modificarlo?
isolation	¿Qué impacto del proveedor debe contenerse y qué recursos seguirían compartidos?
tenancy	¿Qué separación y sharing necesita la población de clientes acordada?
deployment	¿Qué cambia conjuntamente y qué combinaciones de versiones deben coexistir?
execution-model	¿Qué inicia el trabajo y cuánto de su finalización pertenece al request?
scaling	¿Qué carga crece y qué unidad puede ampliarse sin desplazar el límite?

Las respuestas se influyen. Identificar responsabilidades no determina procesos; un cambio de comunicación tampoco resuelve autoridad o coordinación. granularity y modularity permiten revisar el tamaño de las unidades y qué decisiones protegen. Más unidades no demuestra mejor separación ni mayor capacidad.

Explorar alternativas que cambien consecuencias

architecture-profiles ofrece paquetes candidatos, no templates que el problema deba imitar. Un modular-monolith, una variante service-based-architecture o microservices solo merecen comparación si responden a fuerzas reales. El nombre de un profile no demuestra que satisfaga independencia de entrega, operación o recuperación.

architectural-pattern y architectural-tactics aportan posibilidades cuando aparece un problema pertinente. No se diseña acumulando patrones ni eligiendo primero Kubernetes, Kafka o Redis. Una tecnología obligatoria puede acotar candidatos; una tecnología posible necesita explicar qué compromiso realiza y qué límites agrega.

Comparar mediante quality-attribute-trade-offs hace visibles beneficios y costos: separar entrega puede añadir comunicación remota, observación y compatibilidad; compartir recursos puede reducir costo y ampliar impacto. No existe una arquitectura mejor en todos los sentidos. Alternativas artificiales o descartadas de antemano no aportan contraste útil.

trade-off-analysis desarrolla la práctica de comparar candidatos situados frente a drivers, incertidumbres y consecuencias durante su ciclo de vida. estimation aporta aproximaciones cuando una cantidad puede cambiar la preferencia; no hace falta calcular tráfico o almacenamiento por rutina ni convertir la comparación en un score.

Evaluar antes y después de construir

Una revisión por escenarios, un prototipo, benchmark, prueba de carga o spike debe responder una pregunta delimitada. Un prototipo que demuestra conectividad no prueba operación bajo fallos, costo sostenido ni compatibilidad histórica. Registrar entorno y limitaciones evita convertir un resultado favorable en certificado de producción.

fitness-functions puede convertir ciertas expectativas en feedback repetible, por ejemplo sobre dependencias o compatibilidad de versiones. No toda decisión necesita automatización. Conversaciones con operación, pruebas de recuperación y revisión de contratos pueden aportar evidencia diferente y necesaria.

Conservar contexto, alternativas, decisión, consecuencias y supuestos ayuda a revisar. Un ADR es un mecanismo posible, no un nuevo requisito de tooling. La representación debe permitir responder preguntas concretas: contexto para dependencias externas, secuencia para un resultado incierto, deployment para versiones coexistentes.

ISO/IEC/IEEE 42010:2022 distingue arquitectura de su descripción y no prescribe el proceso para producirla. Rozanski y Woods explican cómo views y viewpoints atienden preocupaciones diferentes. Dibujar una vista sirve al razonamiento; un único diagrama sobrecargado no reemplaza decisiones ni evidencia.

Commerce: revisar una dirección de diseño

En este ejemplo propio, Commerce acepta pedidos, autoriza pagos, reserva inventario y organiza envíos. El negocio necesita cambiar de proveedor de Payments sin detener entregas de Orders. Primero se aclara si busca cambios internos localizados o releases independientes en producción: no son la misma obligación.

La propuesta inicial puede conservar deployment común y proteger la integración tras una interface. Otra dirección separa una unidad entregable. El equipo contrasta ambas con los cambios representativos exigidos, las combinaciones soportadas y la capacidad de operación. Una frontera lógica puede resolver el primer problema y no satisfacer una exigencia auténtica de entrega independiente.

Un proveedor SOAP contractual limita integración sin elegir la arquitectura completa. Si Shipping no debe bloquear checkout, se examinan respuesta, ejecución y coordinación; no se deduce automáticamente EDA. Un ensayo puede revelar que un timeout oculta un pago ya autorizado, obligando a revisar el contrato de confirmación y la evidencia de recuperación.

Cada resultado puede ajustar escenario, alcance o candidato. requirements-to-architecture desarrolla esa derivación; aquí importa que la propuesta cambie con lo aprendido en vez de defender un profile elegido antes del problema.

Converger sin cerrar el aprendizaje

Una propuesta suficientemente definida permite implementar el siguiente alcance con decisiones creíbles sobre drivers y riesgos importantes, incertidumbre aceptada y condiciones de revisión. high-level-design desarrolla esa síntesis a un nivel relativo al alcance; deep-dives investiga cuestiones seleccionadas que pueden modificarla. No requieren diseñar todas las clases o tablas ni reemplazan este ciclo general.

Converger también implica acordar qué se hará después de la revisión. En Commerce puede autorizarse un incremento que conserve autoridad de Payments y permita evaluar compatibilidad, mientras queda pendiente decidir otra unidad de deployment. Esa separación solo es válida si el incremento no depende ya de la decisión aplazada. La propuesta debe mostrar qué límites se preservan y qué evidencia permitiría ampliar el alcance.

Revisar con quienes implementan, operan y consumen ayuda a descubrir compromisos omitidos antes de hacerlos costosos. Si un operador no puede distinguir pago pendiente de fallo terminal, mejorar el dibujo no resuelve la carencia. Puede requerirse cambiar el contrato, preparar diagnóstico o reducir el alcance prometido antes de construir.

Overdesign compromete complejidad para necesidades hipotéticas; underdesign ignora obligaciones conocidas. YAGNI no justifica omitir una frontera requerida ni construir anticipadamente todas las variantes. evolutionary-architecture conecta evolución guiada y feedback; aplazar indefinidamente también consume opciones y tiempo.

El siguiente es un bucle de razonamiento del Atlas, no una metodología universal:

Problema y objetivos -> requisitos + restricciones
  -> drivers -> decisiones candidatas -> evaluar / comparar / probar
  -> propuesta -> evidencia de implementación -> revisar cuando corresponda

Puede recorrerse desde distintas entradas y volver sobre acuerdos previos. systems-thinking ayuda a detectar costos desplazados hacia otros actores. system-design-practice conserva el propósito: combinar conocimiento para decidir y aprender, sin equiparar diseño con diagramación, selección tecnológica o exploración interminable.

common-pitfalls ayuda a reconocer dónde ese razonamiento ocultó un supuesto o una consecuencia; no convierte toda decisión discutible en un error universal. design-exercises permite practicar el ciclo con alcance acotado, información nueva y revisión de razones, sin premiar una arquitectura de referencia única.