Capas y reglas: quién importa a quién y cómo se rompe un ciclo

Hay un momento, en toda modularización que avanza, en el que el compilador se planta y dice que hay una dependencia circular entre dos módulos. La reacción instintiva es tratarlo como un obstáculo burocrático y buscar la forma de esquivarlo: fusionar los dos módulos, mover una clase al cajón común, marcar algo más como público. Las tres funcionan y las tres son un error, porque el ciclo no es un problema del sistema de módulos: es un diagnóstico que el sistema de módulos te está entregando gratis. Dos componentes que se necesitan mutuamente son, a efectos de razonamiento, de prueba y de reutilización, un solo componente escrito en dos sitios. Swift no admite ciclos entre módulos y esa restricción —que en otros ecosistemas es opcional y por tanto se ignora— convierte cada intento de acoplamiento bidireccional en un error de compilación que obliga a mirar el diseño. Esta lección trata de cómo se ordenan las capas para que eso ocurra pocas veces, y de qué hacer cuando ocurre.

La dirección de las flechas

Una arquitectura por capas se reduce a una sola afirmación: las dependencias apuntan hacia lo estable. Lo estable es lo que cambia poco y no sabe nada de sus consumidores; lo inestable es lo que cambia con cada requisito nuevo y conoce a todos los demás. En una app iOS eso produce un orden que casi siempre es el mismo.

En la base viven los tipos del dominio y las reglas de negocio: Usuario, Pedido, el cálculo de un precio con impuestos. No importan SwiftUI, no importan la red, no saben si existe una pantalla. Encima, los contratos de acceso a datos, expresados como protocol. Encima, las features, cada una con sus vistas y su estado. Y en la cima, el target de la app, que es el único sitio del proyecto que conoce todas las features a la vez y que existe casi exclusivamente para componer: instanciar las implementaciones reales, inyectarlas y decidir la navegación entre features.

La regla operativa que se deriva es corta y se aplica sin excepciones: una feature nunca importa otra feature. Si FeaturePerfil necesita abrir una pantalla de FeatureAjustes, no la importa; emite una intención —un enum de destino, una clausura de navegación— y el target de la app, que sí conoce a las dos, la resuelve. En cuanto una feature importa a otra, el grafo empieza a colapsar hacia el monolito con manifiestos: la dependencia se propaga transitivamente y la próxima feature heredará las dos.

// Mal: FeaturePerfil sabe de la existencia de FeatureAjustes
import FeatureAjustes
NavigationLink { AjustesView() } label: { Text("Ajustes") }

// Bien: FeaturePerfil emite una intencion, el compositor la resuelve
public enum DestinoPerfil: Hashable { case ajustes, cerrarSesion }

public struct PerfilView: View {
    let alDestino: (DestinoPerfil) -> Void
    public var body: some View {
        Button("Ajustes") { alDestino(.ajustes) }
    }
}

La regla tiene una excepción aparente que conviene desactivar antes de que alguien la use como coartada: dos features que comparten un tipo no necesitan importarse, necesitan que ese tipo baje al dominio. Si FeaturePedidos y FeatureFacturas manejan ambas un Cupon, el Cupon no pertenece a ninguna de las dos; vive abajo, donde ambas pueden verlo sin conocerse. Cada vez que alguien argumenta que la regla no aplica a su caso, lo que casi siempre está describiendo es un concepto de dominio que quedó alojado por accidente en la primera feature que lo necesitó.

Interfaz e implementación en módulos distintos

La separación que más rinde en tiempo de compilación no es la de features: es la de contrato frente a realización. El patrón consiste en publicar dos módulos donde antes había uno.

ClienteAPIInterface contiene el protocol, los tipos que aparecen en su firma y nada más. Es diminuto, no depende de casi nada y su firma cambia raras veces. ClienteAPIEnvivo contiene la implementación real, con URLSession, decodificadores, reintentos y todo lo que eso arrastra. Las features importan solo la interfaz. La app importa las dos y hace la unión.

flowchart TB
App[Target de la app] --> FP[FeaturePerfil]
App --> FA[FeatureAjustes]
App --> Vivo[ClienteAPIEnvivo]
FP --> Iface[ClienteAPIInterface]
FA --> Iface
Vivo --> Iface
Iface --> Dom[Dominio]
style Iface fill:#a6e3a1,color:#11111b
style Dom fill:#a6e3a1,color:#11111b
style Vivo fill:#89b4fa,color:#11111b
style App fill:#cba6f7,color:#11111b

El efecto sobre la compilación es el punto entero del ejercicio. Cuando cambias el cuerpo de un método de ClienteAPIEnvivo, ninguna feature se recompila: su contrato, que es lo único que conocen, no ha cambiado. Solo se recompila la implementación y se vuelve a enlazar. En un módulo único, ese mismo cambio invalidaba todo lo que tocaba el cliente. Además obtienes un segundo beneficio que se nota al probar: los tests de una feature dependen de la interfaz y de un doble, nunca de la red, y por tanto ni siquiera compilan la implementación real.

// Modulo ClienteAPIInterface: minusculo y estable
public protocol ClienteAPI: Sendable {
    func perfil(id: Usuario.ID) async throws -> Perfil
}

// Modulo ClienteAPIEnvivo: cambia a menudo, nadie lo importa salvo la app
public struct ClienteAPIEnvivo: ClienteAPI {
    public init() {}
    public func perfil(id: Usuario.ID) async throws -> Perfil { /* red */ }
}

Advertencia importante: este patrón duplica el número de módulos de la capa que lo aplique. No lo apliques a todo. Reserva la separación para las dependencias que cumplen las dos condiciones a la vez —implementación cara de compilar y muchos consumidores—, porque solo ahí el desacoplamiento paga el manifiesto extra.

Romper un ciclo

Cuando el ciclo aparece, hay tres respuestas legítimas y la elección depende de por qué existe.

Inversión. El caso más común: Autenticacion necesita mostrar la pantalla de login que vive en FeatureLogin, y FeatureLogin necesita a Autenticacion para validar. La solución no es que se importen: es que la capa baja declare un protocol con lo que necesita y que la capa alta lo conforme. La dependencia deja de ser mutua y pasa a apuntar, las dos veces, hacia el módulo estable que declara el contrato.

Extracción. A veces el ciclo señala que hay un tercer concepto atrapado entre los dos. Pedidos y Facturacion se importan mutuamente porque ambos manipulan un Importe con divisa y redondeo. Ese Importe no pertenece a ninguno: pertenece a un módulo nuevo del que dependen ambos. El ciclo desaparece porque el concepto compartido dejó de vivir arbitrariamente en uno de los lados.

// Inversion: el modulo estable declara lo que necesita
// Modulo Autenticacion
public protocol PresentadorDeLogin: Sendable {
    @MainActor func presentarLogin() async -> Credenciales?
}

public actor Sesion {
    private let presentador: any PresentadorDeLogin
    public init(presentador: any PresentadorDeLogin) { self.presentador = presentador }
}

// Modulo FeatureLogin: conforma el protocolo, la flecha apunta hacia abajo
// El target de la app une las dos piezas y nadie importa hacia arriba.

Mediación. Cuando el acoplamiento es de eventos y no de datos —Reproductor quiere avisar de que terminó una pista y Biblioteca quiere reaccionar—, ninguna dependencia directa es correcta en ninguna dirección. Ambos dependen de un módulo de eventos que no conoce a nadie, y la app conecta los cables. Esta es la técnica más potente y la más fácil de abusar: cada evento intermediado es una relación que el compilador ya no puede verificar y que solo existe en tiempo de ejecución.

Hacer cumplir el orden

La regla que solo vive en la cabeza del equipo se erosiona; conviene que algo la compruebe. Una parte la comprueba ya el compilador, gratis: si Dominio no declara dependencia sobre SwiftUI, el import SwiftUI no compila y no hay conversación posible. Para lo que el compilador no ve —una feature que importa otra cuando ambas están declaradas en el mismo paquete— basta una comprobación de texto en integración continua.

# Ninguna feature debe importar otra feature
if grep -rn "^import Feature" Modulos/Sources/Feature*/ ; then
  echo "Violacion de capas: una feature importa otra"
  exit 1
fi

La comprobación es tosca a propósito. Su valor no está en la sofisticación sino en que convierte una discusión recurrente de revisión de código en un fallo de build, es decir, en algo que no requiere que nadie esté prestando atención.