Software Architect · Módulo 04
Hasta un equipo fuerte pierde contra un sistema que no entra en una sola cabeza.
Cognitive load · bounded context · Conway's Law
La arquitectura existe para reducir complejidad innecesaria, no para mostrar el rango intelectual de su autor.
No toda complejidad es igual
Un piloto necesita conocer la aerodinámica del avión. No necesita recordar el número de serie de cada tornillo del asiento del pasajero.
La intrinsic cognitive load es la complejidad del dominio en sí. Un sistema financiero tiene plata, asientos, límites, regulación. Eso no se puede sacar y listo. La extraneous cognitive load es la complejidad extra que crea la arquitectura: dependencias incidentales, magia, side effects no obvios, cinco maneras de hacer lo mismo.
El trabajo del arquitecto es proteger al equipo de la extraneous load. La buena arquitectura no hace simple al dominio, pero lo vuelve comprensible.
El bounded context recorta el ruido
En un aeropuerto, "gate" es la puerta de embarque. En logística, "gate" puede ser el portón del depósito. Misma palabra, mundos distintos.
Un bounded context es un límite dentro del cual el modelo y el lenguaje se mantienen consistentes. El customer en billing y el customer en support muchas veces no son el mismo objeto. Intentar armar un modelo universal de "customer" puede aumentar la carga cognitiva: cada ingeniero tiene que recordar todas las excepciones de todos los dominios.
Un buen bounded context le permite a un ingeniero trabajar localmente: entender el lenguaje, los invariantes y las dependencias justo de esa zona.
Si un cambio te obliga a sostener todo el sistema en la cabeza, las boundaries están mal trazadas.
Ejemplo: un equipo es dueño de checkout
El turno de un restaurante es dueño de la cocina de punta a punta: ingredientes, proceso, emplatado, calidad. No le pregunta a la oficina central por cada pedido.
El equipo de checkout es dueño del cart, del pricing snapshot, del payment intent, de la creación de la orden y del failure handling. Tiene APIs claras hacia catalog e identity. No mete la mano directamente en warehouse — publica un evento OrderPlaced.
Ese corte baja la cognitive load: el equipo entiende su flujo end-to-end y no carga toda la compañía en la cabeza.
Antiejemplo: la capa de shared everything
Una alacena compartida funciona bien hasta que todos empiezan a tirar adentro sus herramientas sin etiquetas.
La carpeta shared se transforma seguido en un cajón de sastre: validators, formatters, domain models, API clients, permissions, constants. Cualquier cambio se vuelve riesgoso, porque nadie sabe quién más depende de ese código.
El código compartido tiene que ser o muy estable o muy chico. Si no, amplifica coupling y cognitive load.
- ¿Se puede explicar el módulo sin referirse a los módulos vecinos? - ¿Dónde, en el sistema, hay demasiado conocimiento implícito? - ¿Qué partes shared cambian con demasiada frecuencia? - ¿Las team boundaries y las architecture boundaries coinciden?