Architecture Decision Axes
Dimensiones para examinar decisiones
Architecture Decision Axes son dimensiones analíticas para examinar decisiones de una arquitectura. Separan preguntas sobre unidades, dependencias, interacción y otros compromisos. No son estilos mutuamente excluyentes, niveles de madurez, tecnologías ni carpetas que determinen el diseño.
Este MOC sigue Knowledge Map V0.3 y organiza navegación. Las explicaciones generales pertenecen a los canonicals; las tablas sintetizan preguntas y tendencias. La clasificación ayuda a describir una arquitectura concreta, sin exigir llenar todos los ejes antes de implementar.
architecture-profile describe un paquete de decisiones sobre varios ejes. architecture-profiles permite comparar aproximaciones nombradas. Microservices no es el eje Decomposition: combina decisiones sobre unidades, contratos, comunicación, deployment, datos, aislamiento y otras dimensiones.
Diez preguntas complementarias
| Axis | Pregunta principal |
|---|---|
| decomposition | ¿Qué unidades significativas y fronteras existen? |
| dependency-structure | ¿Quién depende de quién, de qué propiedad y en qué dirección? |
| communication | ¿Cómo intercambian información, requests, resultados o señales? |
| coordination | ¿Cómo alinean acciones y resultados múltiples participantes? |
| data-ownership | ¿Quién tiene autoridad sobre cada estado o información? |
| isolation | ¿Qué fallos, recursos y efectos deben quedar contenidos? |
| tenancy | ¿Qué se comparte o separa entre tenants? |
| deployment | ¿Qué se instala y actualiza junto o por separado? |
| execution-model | ¿Cómo, cuándo y bajo qué lifecycle ejecuta trabajo? |
| scaling | ¿Qué capacidad puede cambiar y qué la limita? |
Preguntas diferentes no significan decisiones sin interacción. Los ejes separan el foco de análisis; no son variables independientes en sentido matemático ni etapas que deban completarse linealmente.
Una necesidad de entrega puede cambiar el corte, una integración puede revelar dependencia de datos y un fallo puede llevar a revisar interacción. Es razonable recorrer varios ejes y regresar al driver cuando aparece evidencia nueva.
Decomposition tiene un solo canonical
El Knowledge Map presenta Decomposition bajo Architecture Foundations y Architecture Decision Axes. Es el mismo concepto observado desde dos recorridos, no permiso para crear dos definiciones.
Su canonical vive físicamente en Architecture Foundations y conserva el ID decomposition. architecture-foundations ofrece su entrada fundacional; este MOC utiliza ese mismo enlace para examinar la decisión. La ruta organiza contenido y no participa en identidad ni resolución.
Knowledge Map no equivale al filesystem. Tampoco se necesita una Perspective Note artificial para repetir el concepto. La navegación puede converger en una definición y conservar preguntas de entrada diferentes.
Commerce como ejemplo transversal
El ejemplo común usa Orders, Payments, Inventory y Shipping. No es un diseño recomendado para todo comercio online ni un caso de producción del Atlas; permite comparar los ejes con responsabilidades reconocibles.
En Decomposition examinamos si esas unidades tienen responsabilidad y fronteras significativas. En Dependency Structure investigamos qué contratos, datos privados o capacidades conocen y necesitan. En Communication describimos cómo solicitan trabajo, reciben resultados y transmiten hechos.
Para Place Order, una política ilustrativa crea el pedido, reserva Inventory, autoriza Payments, confirma Orders e inicia Shipping. Coordination examina quién conduce el progreso, qué orden importa y cómo resolver éxito parcial. Data Ownership asigna autoridad sobre pedido, pago, stock y envío. Isolation pregunta qué impide que Payments degradado consuma toda la capacidad de Orders.
Un mensaje PaymentRequested describe intercambio, no quién confirma ni cuándo termina el proceso. OrderWorkflow puede conducirlo sin poseer todos los estados. Pools separados pueden contener espera y conservar la dependencia de una autorización válida. El ejemplo muestra decisiones complementarias, no etapas obligatorias.
La variante Commerce SaaS añade Tenant A y Tenant B. Tenancy examina qué runtime, datos y capacidad comparten. Deployment compara una aplicación común con unidades separadas y pregunta si Payments cambia sin actualizar otros participantes. Execution Model distingue Orders API, PaymentSettlement diferido, InventoryReconciliation programado/batch y Shipping consumer. Un artifact puede reunirlos; cada actividad debe conservar el contexto permitido del tenant.
Si tráfico de Orders crece ×4, autorizaciones Payments ×4, escrituras Inventory ×2 y actualizaciones Shipping ×1,5, scaling pregunta qué recurso limita cada recorrido. Replicar toda la aplicación y ampliar capacidades separadas son variantes; ambas pueden conservar una cuota de pago o estado compartido como límite. Tenant A puede concentrar la demanda aunque cada tenant tenga su partición.
Mismas responsabilidades, variantes diferentes
Las cuatro unidades amplias admiten, por ejemplo:
- Módulos en un proceso con llamadas locales.
- Módulos en un proceso con mensajería interna.
- Servicios entregados por separado con llamadas síncronas de red.
- Servicios entregados por separado con mensajería asíncrona.
Estas realizaciones no son equivalentes. Cambian disponibilidad, espera, recursos, capacidad de entrega y recuperación. Lo comparable es el reparto amplio de responsabilidades, no una promesa de resultados idénticos.
Otra variación mantiene la división y cambia Orders → implementación concreta de Payments por Orders → PaymentPort, suministrando un adaptador. Eso puede proteger conocimiento de implementación y conservar dependencia operacional. Una elección de canal no demuestra automáticamente que cambió la dirección de código.
Para contrastarlas, elegir un cambio de proveedor y una respuesta de pago perdida. Observar qué se modifica, quién puede continuar y qué evidencia falta. La comparación necesita esos casos, no un ranking de variantes.
Profiles como combinaciones
La tabla recoge tendencias ilustrativas, no definiciones universales ni una matriz de todos los ejes:
| Profile | Decomposition | Dependency Structure | Communication |
|---|---|---|---|
| monolith | Unidades dentro de una frontera amplia. | Dependencias internas variables. | Comúnmente local, más integración externa. |
| modular-monolith | Módulos con límites protegidos. | Contratos y accesos deliberados. | Comúnmente local; mensajes internos posibles. |
| microservices | Servicios con responsabilidades delimitadas. | Contratos remotos y públicos, según realización. | Comunicación por red entre servicios. |
El nombre no garantiza encapsulación, independencia ni bajo coupling. service-based-architecture y service-oriented-architecture permiten continuar hacia otros paquetes actuales sin reducirlos a granularidad o protocolo.
No se completa ahora una matriz diez ejes por cinco perfiles. architecture-profiles conserva una comparación más amplia; esta tabla selecciona los tres primeros ejes para conectar aproximaciones conocidas. Coordination, Data Ownership e Isolation también atraviesan perfiles: un Modular Monolith puede coordinar cambios locales y proteger autoridad lógica compartiendo runtime; Microservices puede separar ejecución y conservar coordinación y recursos comunes. Ninguna etiqueta demuestra ownership o contención efectivos.
Recorridos según la incertidumbre
«Tenemos carpetas Orders y Payments». Comenzar por Decomposition y continuar hacia code-partitioning-strategies. Preguntar responsabilidad, accesos y cambios que deberían quedar locales. Un directorio no demuestra una frontera, pero puede ayudar a hacerla efectiva.
«Los servicios no se referencian en código». Ir a Dependency Structure. Revisar schemas compartidos, contratos de eventos, necesidad de resultados y release. Separar procesos no elimina esas dependencias.
«Usamos async, entonces somos independientes». Ir a Communication. Aclarar si se espera aceptación, respuesta o finalización; comprobar si hay buffering durable y cómo se manejan resultados inciertos. Una API no bloqueante y un workflow independiente no son la misma propiedad.
«Tenemos eventos; ya no hay coordinación». Ir a coordination. Buscar quién decide confirmar, detecta procesos incompletos y retoma trabajo. Choreography distribuye esas políticas; no las elimina.
«Cada servicio tiene una base, entonces controla sus datos». Ir a data-ownership. Separar bytes no demuestra autoridad semántica; leer o copiar un hecho ajeno tampoco transfiere autoridad.
«Son containers diferentes; un fallo no se propaga». Ir a isolation. Identificar efecto, recurso y dominio compartido. Separar proceso no protege automáticamente un broker, storage o cuota comunes.
«Tenemos una base por cliente; ya está resuelto el tenant». Ir a tenancy. Distinguir contexto, acceso, recursos compartidos y lifecycle. Una base dedicada no demuestra separación de todo efecto.
«Tenemos pipelines separados; podemos actualizar independientemente». Ir a deployment y después a deployability. Identificar unidades, contratos y schemas compatibles, y evaluar seguridad y esfuerzo reales de la entrega.
«Usamos async; todo es trabajo en background». Ir a execution-model. Separar espera, trigger y finalización. Un handler, consumer y batch pueden compartir deployment sin compartir lifecycle.
«Tenemos más réplicas; el sistema ya puede crecer». Ir a scaling. Identificar unidad, costo del trabajo, estado, distribución y siguiente límite downstream. CPU disponible no demuestra que una cuota externa o partición caliente tenga margen.
«¿Cómo se organiza cada unidad por dentro?» Continuar con internal-structure. Decomposition establece la unidad observada; estructuras internas definen organización dentro de ella. Las dimensiones pueden componerse jerárquicamente.
Drivers, qualities y evidencia
architectural-drivers permite recuperar por qué interesa una decisión. quality-attributes conecta preocupaciones, escenarios, prioridades y evidencia. Los axes describen compromisos; no son Quality Attributes ni medidas universales de calidad.
Un corte más fino puede favorecer cambios localizados o delivery y aumentar comunicación, operación y costo. Una interfaz puede proteger variación y agregar contratos que mantener. Una interacción buffered puede permitir continuidad del productor y diferir el resultado del consumidor.
Las relaciones son hipótesis situadas. quality-attribute-trade-offs ayuda a comparar consecuencias, y quality-attribute-scenarios a formular resultados verificables. No hay una escala que obligue a avanzar de Monolith a Microservices o de llamadas a mensajes.
design-process muestra cómo usar los diez ejes para interrogar candidatos a partir de un problema. requirements-to-architecture desarrolla el paso previo de aclarar necesidades e implicaciones. Los ejes organizan preguntas, no un orden fijo de diseño ni respuestas deducibles automáticamente de un requisito. system-design-practice conecta esas prácticas sin duplicar las definiciones canónicas.
high-level-design emplea los ejes para detectar omisiones relevantes en la síntesis, con detalle proporcional a los drivers. deep-dives puede concentrarse en Coordination, Communication y Data Ownership para un pago incierto, o en Scaling y Deployment para un límite de capacidad. No necesita desarrollar todos los ejes por igual.
Decisiones relacionadas, explícitas o accidentales
Decomposition puede influir en Deployment y Scaling sin imponer su granularidad. Data Ownership afecta acuerdos de Coordination; Isolation puede cambiar capacidad aprovechable y cost-efficiency. Execution Model condiciona cómo aumenta trabajo útil. Tenancy introduce demandas de recursos y separación; Communication añade costos y recorridos de fallo. Son interacciones situadas, no leyes ni variables independientes.
Un Architecture Profile es un paquete coherente de decisiones sobre varios ejes. Dos sistemas llamados Microservices pueden diferir materialmente en coordinación, autoridad sobre datos, aislamiento, tenancy, ejecución y capacidad. El nombre no sustituye examinar esas decisiones; tampoco «muchos servicios» describe por sí solo todo el paquete.
Si un eje no fue decidido deliberadamente, el sistema sigue teniendo una respuesta. Tablas que todos modifican pueden establecer autoridad accidental; pools comunes dejan efectos compartidos; replicar toda la aplicación fija una unidad de Scaling. El trabajo arquitectónico hace visibles esas respuestas y sus consecuencias para poder evaluarlas.
Cobertura de V0.3
Los diez Architecture Decision Axes de V0.3 están materializados y conectados mediante IDs estables. No queda un eje pendiente en esta rama. Sus documentos conservan status draft: cobertura editorial no significa madurez ni validación de una arquitectura concreta.
Los ejes son preguntas de análisis, no un checklist puntuable. Ningún profile queda definido por un único eje ni una implementación mejora por llenar todas las celdas. architecture-profiles conserva una comparación selectiva; los canonicals permiten profundizar donde aparece incertidumbre.