Características arquitectónicas y trade-offs
Neal Ford y Mark Richards abren con la Primera Ley de la Arquitectura de Software: everything in software architecture is a trade-off; if you think you've found something that isn't a trade-off, you haven't looked hard enough. Y agregan una segunda: *el why importa más que el how***.
Las -ilities
Una característica arquitectónica es una propiedad que el sistema debe cumplir sin ser un requisito funcional. Se agrupan en tres familias:
- Operacionales: disponibilidad, performance, escalabilidad.
- Estructurales: modularidad, extensibilidad, mantenibilidad.
- Transversales: seguridad, accesibilidad, privacidad.
La trampa es querer todas. Priorizar tres y nombrar en voz alta lo que se resigna es el trabajo real.
Acoplamiento y cohesión
Robert C. Martin propuso métricas de paquete que siguen siendo el mejor vocabulario disponible:
- Ca (aferente): cuántos módulos externos dependen de este.
- Ce (eferente): de cuántos módulos externos depende este.
- Inestabilidad:
I = Ce / (Ca + Ce), de 0 (estable) a 1 (inestable). - Abstracción (
A): proporción de tipos abstractos sobre el total.
La secuencia principal es I + A = 1, y la distancia D = |A + I − 1| marca dos extremos feos: la zona de dolor (concreto y estable) y la zona de inutilidad (abstracto y sin usuarios).
Quantum
En The Hard Parts, un quantum arquitectónico es un artefacto desplegable de forma independiente, con alta cohesión funcional y alto acoplamiento estático. Un monolito con una sola base suele ser un quantum; partirlo en servicios crea varios.