Software Architecture
Explica cómo cohesión, acoplamiento y connascence permiten evaluar límites, conocimiento compartido y propagación de cambios entre módulos y servicios.
La calidad de un límite puede evaluarse observando qué responsabilidades permanecen juntas y qué cambios se propagan a otras partes. Cohesión, acoplamiento y connascence permiten razonar sobre ese costo de cambio.
La arquitectura intenta localizar cambios. Para lograrlo necesita módulos con responsabilidades relacionadas y dependencias explícitas.
No existe software sin acoplamiento. El objetivo es mantenerlo visible, débil cuando cruza límites y fuerte únicamente donde protege una responsabilidad común.
Un módulo tiene alta cohesión cuando sus elementos:
Inventory
├── disponibilidad
├── reservas
├── movimientos
└── reglas de stockEstas responsabilidades tienen relación semántica. En cambio, un módulo CommonService que valida usuarios, envía correos, calcula impuestos y genera PDFs posee baja cohesión.
La cohesión puede evaluarse en distintos niveles.
Elementos juntos por comodidad, como una carpeta utils. Es la forma más débil porque no existe una razón común de cambio.
Operaciones agrupadas porque ocurren en el mismo momento, por ejemplo inicialización. Puede ser válida, pero no siempre representa una capacidad estable.
Elementos siguen un orden, aunque no compartan modelo. Es frecuente en scripts y workflows.
Las partes colaboran alrededor de los mismos datos, invariantes o propósito. Suele producir límites más estables.
El acoplamiento aparece cuando una parte conoce algo de otra.
El consumidor conoce una interfaz estable. Es inevitable y, si el contrato es pequeño, suele ser saludable.
Varias partes dependen de la misma estructura o tabla. Puede volverse peligroso cuando comparten escritura.
Una operación debe ocurrir antes o después de otra. Por ejemplo, confirmar un pedido solo después de reservar stock.
El consumidor conoce reglas internas del proveedor. Es más grave que compartir tipos porque el significado se propaga.
Dos componentes deben publicarse juntos para conservar compatibilidad.
Comparten pool, broker, región o punto de fallo. Aunque el código esté separado, la operación sigue unida.
Dos elementos son connascentes cuando un cambio en uno exige un cambio coordinado en el otro para mantener corrección.
Cliente y servidor deben usar el mismo campo orderId.
Ambos esperan que el valor sea un UUID.
Una función depende del orden de argumentos. Es más frágil que usar un objeto nombrado.
Dos partes conocen un valor especial como status = 4.
Productor y consumidor implementan el mismo hash o cifrado.
Una parte debe responder dentro de una ventana concreta.
Ambas partes deben referirse exactamente a la misma entidad o mensaje.
La fuerza importa. Connascence por nombre suele ser más fácil de gestionar que por algoritmo o timing. La distancia también importa: una dependencia fuerte dentro de un módulo es menos peligrosa que entre servicios remotos.
alta cohesión interna
+ contratos pequeños entre límites
+ connascence fuerte mantenida cerca
= cambios más localizadosSupón este servicio:
class OrderService {
validateCustomer() {}
reserveInventory() {}
authorizePayment() {}
sendEmail() {}
generateMonthlyReport() {}
}Parece centralizar el flujo, pero mezcla capacidades con ritmos, datos y fallos distintos.
Una separación más cohesionada puede ser:
Orders
→ posee estados y reglas del pedido
Inventory
→ posee stock y reservas
Payments
→ posee intentos y resultados
Notifications
→ entrega mensajes
Reporting
→ consume proyeccionesOrders coordina mediante contratos. Esto no elimina acoplamiento: ahora debe elegir sincronía, eventos, errores y consistencia. La mejora consiste en hacer explícita la colaboración y evitar ownership compartido.
Pregunta:
El historial de commits ayuda: archivos que cambian juntos repetidamente pueden señalar cohesión real o acoplamiento accidental.
Duplicar una transformación pequeña puede reducir acoplamiento entre contextos. Eliminar toda duplicación mediante una librería compartida puede crear coordinación permanente.
Un módulo puede ser grande y cohesivo si posee un dominio complejo. El tamaño por sí solo no indica mala arquitectura.
Interfaces no reducen acoplamiento si exponen el mismo modelo interno. Una abstracción filtrante conserva connascence fuerte.
Los eventos reducen acoplamiento temporal, pero añaden acoplamiento de schema, orden, duplicación y operación.
Dos microservicios pueden estar fuertemente unidos por llamadas síncronas, despliegues coordinados y base compartida.
Aumenta dependencia central y mezcla dominios. Extrae únicamente conceptos verdaderamente estables y compartidos.
Reducir imports no garantiza mejor dominio. Métricas de ciclos y dependencias necesitan interpretación semántica.
Es imposible. El objetivo es elegir formas débiles y mantener las fuertes dentro de límites cercanos.
utils suele indicar baja cohesión?Modularidad, encapsulación y ocultamiento de información convierte estos criterios en límites que controlan qué puede conocer y modificar cada parte.