Gestionar las dependencias: dirección, ciclos y estabilidad

Por qué importa la dirección

Existe una dependencia cuando un módulo necesita otro para compilarse, ejecutarse o comportarse correctamente. Dibújala como una flecha del módulo que depende al módulo del que depende: de Pago a Precios. La flecha te dice algo importante sobre el cambio. Si Precios cambia su interfaz o su comportamiento, puede que Pago tenga que cambiar; si Pago cambia, a Precios no le afecta. Los cambios viajan en sentido contrario a las flechas. Así que la dirección de cada dependencia es una decisión sobre quién se verá afectado por los cambios de quién.

A los arquitectos les importan dos tipos de dirección que es fácil confundir. El flujo de control es quién llama a quién en tiempo de ejecución. La dependencia de código fuente es quién importa, referencia o se compila contra quién. Normalmente apuntan en el mismo sentido, pero no tienen por qué. Un framework llama a tu código sin depender de él (la Sección 0.3 lo llamó inversión de control), y, con una interfaz, un módulo de alto nivel puede llamar a uno de bajo nivel mientras la dependencia de código fuente apunta en sentido contrario. Esa libertad para elegir la dirección de la dependencia de código fuente con independencia del flujo de control es la herramienta más potente de esta sección.

Entre servicios, la dirección se manifiesta como conocimiento. Si Pedidos llama a la API de Facturación, Pedidos depende de Facturación y tiene que cambiar cuando cambia la API de Facturación. Si Pedidos publica un evento que Facturación consume, la dependencia se invierte: Facturación depende del contrato de eventos de Pedidos, y Pedidos no sabe que Facturación existe (Sección 3.2). Por tanto, elegir entre una llamada y un evento es en parte una elección sobre la dirección de la dependencia.

El Principio de dependencias acíclicas

Robert C. Martin formuló tres principios para las dependencias entre componentes, primero en artículos y ponencias a mediados de la década de 1990 y después en Agile Software Development: Principles, Patterns, and Practices (2002) y Clean Architecture (2017). El primero, el Principio de dependencias acíclicas (ADP), dice que el grafo de dependencias entre componentes no debe contener ciclos: debe ser un grafo acíclico dirigido.

Un ciclo de dependencias, como que Pedidos dependa de Notificaciones, Notificaciones dependa de Clientes y Clientes dependa de Pedidos, convierte tres componentes en uno. Ninguno puede compilarse ni probarse sin los demás; un cambio en cualquiera puede propagarse por el bucle hasta volver a él mismo; ninguno puede lanzarse por separado; y nadie puede decir cuál compilar primero. Martin presenta el principio con lo que él llama el síndrome de la mañana siguiente: te vas a casa con código que funciona y vuelves al día siguiente para encontrarlo roto porque otra persona cambió algo de lo que dependes. Su remedio es dividir el sistema en componentes que se lanzan por separado, y eso solo funciona si las dependencias entre ellos no contienen ciclos. Los ciclos también hacen imposible extraer más adelante un componente como biblioteca o servicio, porque arrastra consigo todo el bucle.

El Java Platform Module System impone el ADP entre módulos: la Java Language Specification establece que es un error de compilación que un módulo dependa, directa o indirectamente, de sí mismo. La mayoría de los demás lenguajes permiten ciclos entre paquetes, así que los equipos los detectan con herramientas. Los ciclos entre clases dentro de un mismo componente pequeño son menos dañinos, y Martin Fowler, entre otros, los tolera ahí; el principio importa sobre todo entre componentes que construyen y lanzan personas distintas.

Romper ciclos

Todo ciclo puede romperse, y hay dos técnicas habituales. Ambas se muestran en el diagrama siguiente para un ciclo en el que Pedidos llama a Notificaciones para enviar una confirmación y Notificaciones vuelve a llamar a Pedidos para leer los detalles del pedido.

Inversión de dependencias. Notificaciones declara una interfaz que describe exactamente lo que necesita, por ejemplo OrderLookup con un solo método, y Pedidos la implementa. La flecha de Notificaciones a Pedidos apunta ahora en sentido contrario: Pedidos depende de Notificaciones (para llamarlo y para implementar su interfaz), y Notificaciones no depende de nada de Pedidos. Esto es la inversión de dependencias, que la Sección 3.5 trata como la D de SOLID. El detalle clave es la propiedad: la interfaz pertenece al módulo que la usa, no al que la implementa.

Extraer un componente nuevo. Averigua qué necesitan realmente las dos partes la una de la otra, a menudo un pequeño modelo o contrato compartido, y trasládalo a un componente nuevo del que dependan ambas. Aquí, Pedidos publica un tipo de evento definido en un componente de eventos de pedidos, y Notificaciones lee los detalles del pedido del evento en lugar de volver a llamar. Ambos dependen del nuevo componente y este no depende de ninguno, así que es más estable que cualquiera de los dos: exactamente lo que pide el siguiente principio.

El Principio de dependencias estables y la inestabilidad

Algunos componentes cambian a menudo (interfaces de usuario, integraciones con socios, funciones nuevas); otros deberían cambiar rara vez (conceptos centrales del dominio, contratos compartidos, gestión del dinero). El Principio de dependencias estables (SDP) dice: depende en la dirección de la estabilidad. Un componente pensado para ser fácil de cambiar no debería tener como dependiente a un componente difícil de cambiar, o también se volverá difícil de cambiar.

Martin mide la estabilidad a través de las dependencias, no de la frecuencia con que se edita el código. Un componente del que dependen muchos otros es estable en el sentido de que es costoso de cambiar: cada cambio corre el riesgo de romper a sus dependientes. Un componente que depende de muchos otros y no tiene dependientes es inestable: nada le impide cambiar, y sus dependencias pueden obligarle a hacerlo. Usando el acoplamiento aferente (Ca, entrante) y el acoplamiento eferente (Ce, saliente) de la Sección 3.2, la inestabilidad es:

I = Ce / (Ca + Ce)

I va de 0 a 1. I = 0 significa solo dependencias entrantes: máximamente estable, responsable ante muchos, sin depender de nada. I = 1 significa solo dependencias salientes: máximamente inestable, nada depende de él. El SDP, expresado como métrica, dice que I debería disminuir a lo largo de cada flecha de dependencia: cada componente debería depender de componentes con una I menor que la suya. Una dependencia de un componente estable (I = 0.1) a uno volátil (I = 0.8) es una señal de alerta; el arreglo habitual vuelve a ser la inversión de dependencias, colocando una interfaz en un lugar estable.

El Principio de abstracciones estables y la secuencia principal

La estabilidad tiene un costo: un componente con una I cercana a 0 es difícil de cambiar. Si está lleno de código concreto, el sistema se vuelve rígido. El Principio de abstracciones estables (SAP) lo resuelve: un componente debe ser tan abstracto como estable. Los componentes estables deben consistir sobre todo en interfaces y tipos abstractos, para que su comportamiento pueda ampliarse con nuevas implementaciones en otro lugar sin modificarlos; los componentes inestables pueden ser concretos, porque de todos modos son fáciles de cambiar. El SDP y el SAP juntos equivalen al principio de inversión de dependencias aplicado a componentes enteros: las dependencias apuntan hacia la estabilidad, y la estabilidad va unida a la abstracción.

El grado de abstracción se mide como A = Na / Nc, donde Na es el número de clases abstractas e interfaces del componente y Nc el número total de clases. A = 0 significa totalmente concreto; A = 1 significa nada más que abstracciones. Representar A frente a I da un cuadrado. La línea que va de (I = 0, A = 1) a (I = 1, A = 0) es la secuencia principal: estable y abstracto en un extremo, inestable y concreto en el otro, con mezclas equilibradas entre ambos. La distancia a ella es:

D = |A + I - 1|

D va de 0 (sobre la línea) a 1 (en una esquina lejana). La esquina cercana a (0, 0) es la zona de dolor: estable, porque mucho depende de ello, y concreto, así que cualquier cambio es a la vez necesario y doloroso. Un esquema de base de datos que todos los módulos leen directamente vive aquí. Martin señala que algunos componentes están ahí sin causar daño, como una biblioteca de utilidades concreta y madura que nunca necesita cambiar; la zona solo duele en los componentes que son volátiles. La esquina cercana a (1, 1) es la zona de inutilidad: abstracciones de las que nada depende, normalmente interfaces que quedaron tras una refactorización o que se diseñaron para una extensión que nunca llegó.

Organización en capas estricta y relajada

La organización en capas (layering) es la regla de dependencia más antigua y común: organizar los módulos en capas, como presentación, aplicación o dominio, y persistencia, y permitir que cada capa use solo las capas inferiores. Las capas inferiores no saben nada de las superiores, así que puede añadirse una nueva interfaz de usuario sin cambiar el dominio. La organización en capas es un estilo arquitectónico por derecho propio (Sección 5.2); aquí lo que interesa es la regla de dependencia que impone.

En la organización en capas estricta (cerrada), cada capa solo puede usar la capa inmediatamente inferior. Así, cada capa oculta todo lo que tiene debajo, y sustituir una capa inferior solo afecta a otra capa; el precio es el código de paso, en el que la capa intermedia se limita a reenviar llamadas a las que no tiene nada que añadir. En la organización en capas relajada (abierta), una capa puede usar cualquier capa inferior. Eso elimina el código repetitivo, pero significa que un cambio en la capa inferior puede afectar a todas las capas superiores. Muchos sistemas reales mezclan ambas y marcan como abiertas capas concretas, como una capa compartida de logging o de utilidades que todos pueden usar.

La organización en capas clásica tiene una debilidad conocida: la capa de dominio depende de la capa de persistencia, así que las reglas de negocio más importantes dependen de detalles de la base de datos. Las arquitecturas hexagonal, de cebolla y limpia (Sección 5.6) aplican la inversión de dependencias para corregirlo: el dominio es dueño de interfaces como OrderRepository y el código de persistencia las implementa, de modo que todas las dependencias de código fuente apuntan hacia dentro, hacia el dominio.

Comprobar automáticamente las reglas de dependencia

Las reglas de dependencia escritas solo en una wiki se incumplen en cuestión de semanas. La forma fiable de mantenerlas es expresarlas como comprobaciones ejecutables que se ejecutan en la compilación y la hacen fallar cuando se viola una regla. Una comprobación así es una función de aptitud (fitness function) arquitectónica, una idea presentada en la Sección 2.8 y desarrollada en la Sección 11.3. Tres herramientas de código abierto muy usadas cubren los principales ecosistemas.

ArchUnit (Java y otros lenguajes de la JVM) te permite escribir reglas de arquitectura como pruebas unitarias normales: qué paquetes pueden acceder a cuáles, definiciones de capas y ausencia de ciclos entre porciones del código base. dependency-cruiser (JavaScript y TypeScript) analiza las importaciones y las valida contra reglas de un archivo de configuración, y su configuración inicial ya prohíbe las dependencias circulares. import-linter (Python) comprueba contratos declarados en un archivo de configuración; entre sus tipos de contrato están las importaciones prohibidas, las capas, la independencia entre módulos hermanos, los módulos protegidos y los hermanos acíclicos.

@ArchTest
static final ArchRule layers = layeredArchitecture()
    .consideringAllDependencies()
    .layer("Web").definedBy("..web..")
    .layer("Domain").definedBy("..domain..")
    .layer("Persistence").definedBy("..persistence..")
    .whereLayer("Web").mayNotBeAccessedByAnyLayer()
    .whereLayer("Domain").mayOnlyBeAccessedByLayers("Web", "Persistence")
    .whereLayer("Persistence").mayNotBeAccessedByAnyLayer();

@ArchTest
static final ArchRule noCycles =
    slices().matching("com.shop.(*)..").should().beFreeOfCycles();

// .dependency-cruiser.js
module.exports = {
  forbidden: [
    { name: "no-circular", severity: "error",
      from: {}, to: { circular: true } },
    { name: "domain-not-to-db", severity: "error",
      comment: "Domain code must use repository interfaces, not the database",
      from: { path: "^src/domain" },
      to: { path: "^src/db" } },
  ],
};

# .importlinter
[importlinter]
root_package = shop

[importlinter:contract:layers]
name = Web above domain above adapters
type = layers
layers =
    shop.web
    shop.domain
    shop.adapters

[importlinter:contract:features-independent]
name = Feature packages do not import each other
type = independence
modules =
    shop.catalogue
    shop.ordering
    shop.payments

Observa que la regla de ArchUnit anterior permite que Persistence acceda a Domain pero no al revés: es la organización centrada en el dominio que acabamos de describir, no la organización en capas clásica. Reglas como estas son baratas de añadir, se ejecutan en segundos y convierten un diagrama de arquitectura en algo que la compilación defiende. Cuando un código base existente ya incumple una regla, la mayoría de las herramientas pueden registrar las infracciones actuales como línea base y fallar solo con las nuevas, de modo que la regla impide que las cosas empeoren desde el día en que se introduce.

Cómo gestionan las dependencias los profesionales

Los arquitectos con experiencia tienen una imagen del grafo de dependencias entre componentes y la consultan con regularidad, generada a partir del código en lugar de dibujada a mano. Deciden qué componentes deben ser estables (conceptos del dominio, contratos compartidos) y cuáles volátiles (interfaces de usuario, integraciones), y hacen que las flechas apunten de lo volátil a lo estable. Tratan los ciclos nuevos como fallos de compilación, no como cuestiones de estilo. Y aplican el mismo razonamiento entre servicios: las bibliotecas compartidas y los esquemas de eventos compartidos son los componentes estables de un sistema distribuido, que merecen superficies mínimas y un versionado cuidadoso, mientras que las partes internas de cada servicio siguen siendo libres de cambiar.

Nada de esto exige calcular las métricas con precisión. Su valor está en las preguntas que obligan a hacerse: ¿en qué sentido debería apuntar esta flecha?, ¿qué les pasa a todos los que están aguas arriba si esto cambia?, ¿es este componente tan abstracto como exige el número de cosas que dependen de él? La Sección 3.5 continúa con los principios SOLID, que aplican las mismas ideas dentro de los componentes y entre ellos.