Capas: dominio, datos y presentación

La palabra capa se usa con una ligereza que le ha quitado casi todo el significado. En muchos proyectos designa simplemente un grupo de carpetas, y entonces no impone nada: los tipos de red aparecen en la vista, el modelo de dominio hereda del formato del servidor y cambiar un campo de la interfaz obliga a tocar el analizador de respuestas. Una capa de verdad es otra cosa, y se reconoce por una propiedad única y verificable: la dirección en la que se permite mirar. Dominio, datos y presentación no son tres cajones donde repartir archivos, sino tres regiones ordenadas por dependencia, y toda la potencia del diseño está en que esa flecha apunte siempre hacia el mismo lado, incluso cuando el atajo contrario ahorraría veinte minutos.

Las tres capas y la única regla que importa

El dominio contiene los tipos que describen el problema y las reglas que los gobiernan, y no importa nada: ni SwiftUI, ni la red, ni la base de datos. La capa de datos sabe hablar con el mundo, es decir, con URLSession, con SwiftData, con el Keychain, y su misión es entregar tipos de dominio ya traducidos. La presentación observa el dominio y dibuja. La regla es una sola: las dependencias apuntan hacia dentro, hacia el dominio, y nunca hacia fuera.

// Dominio: puro, sin dependencias de framework
struct Nota: Identifiable, Equatable {
    let id: UUID
    var titulo: String
    var cuerpo: String
    var esPublicable: Bool { !titulo.isEmpty && cuerpo.count >= 10 }
}

enum NotasError: Error, Equatable {
    case sinConexion
    case noEncontrada
    case rechazadaPorElServidor(motivo: String)
}

// Dominio: el contrato que la capa de datos deberá cumplir
protocol NotasRepository: Sendable {
    func todas() async throws -> [Nota]
    func guardar(_ nota: Nota) async throws
}

Observa también que esPublicable es una regla, no un campo, y que vive junto a los datos que la determinan. Cuando esa misma regla se escribe en el body de una vista, deja de ser conocimiento del problema y pasa a ser detalle de una pantalla, con el efecto secundario de que la segunda pantalla que la necesite la copiará ligeramente distinta. La capa de dominio es, entre otras cosas, el sitio donde una regla solo puede existir una vez.

El detalle que decide todo está en las dos últimas líneas: el protocolo vive en el dominio, no en la capa de datos. Quien define el contrato es el que lo necesita, y quien lo implementa es el que sabe del mundo. Esa inversión es la que permite compilar y probar el dominio entero sin que exista una sola línea de red en el proyecto.

flowchart TD
P[Presentacion vistas y modelos de vista] --> D[Dominio tipos reglas y protocolos]
DAT[Datos red base de datos y llavero] --> D
DAT -.->|traduce DTO a modelo| D
P -.->|nunca conoce el transporte| DAT
style D fill:#a6e3a1,color:#11111b
style DAT fill:#89b4fa,color:#11111b

El repository como frontera, no como envoltorio

Un repository que se limita a llamar a un endpoint y devolver lo que llegue no es una frontera: es una capa de reenvío con un nombre prestigioso. La frontera aparece cuando el repositorio asume tres responsabilidades que la vista jamás debería ver.

// Capa de datos: conoce el transporte y lo esconde
struct NotaDTO: Decodable {
    let id: String
    let title: String
    let body: String?
}

final class NotasRepositoryHTTP: NotasRepository {
    private let cliente: HTTPCliente
    private let local: NotasLocalStore

    func todas() async throws -> [Nota] {
        do {
            let dtos: [NotaDTO] = try await cliente.get("/notes")
            let notas = dtos.compactMap(Nota.init(dto:))   // traduccion
            try await local.reemplazar(con: notas)          // politica de cache
            return notas
        } catch is URLError {
            return try await local.todas()                  // degradacion
        } catch let error as HTTPError where error.codigo == 404 {
            throw NotasError.noEncontrada                   // error de dominio
        }
    }
}

Por qué la vista no debe conocer la red

El argumento fuerte no es la limpieza estética, sino que cada dato del transporte que se filtra a la interfaz crea un acoplamiento entre dos cosas que cambian a ritmos distintos y por motivos distintos. El servidor cambia cuando lo decide otro equipo, a veces otra empresa; la interfaz cambia cuando lo decide diseño, cada dos semanas. Unir por accidente dos calendarios ajenos garantiza que cada uno de ellos genere trabajo en el otro lado. El servidor renombra un campo o añade un envoltorio de paginación, y de pronto hay que tocar vistas. Además, la vista que conoce la red hereda su vocabulario de fallos, y termina mostrando al usuario mensajes que hablan de códigos y de tiempos de espera en lugar de hablar de notas.

Hay un tercer efecto, menos visible y más costoso a largo plazo: la vista acoplada al transporte no se puede previsualizar ni probar sin simular un servidor, y lo que no se previsualiza barato termina sin previsualizarse. El acoplamiento no solo propaga cambios; también apaga las herramientas que harían el cambio seguro.

Dónde esta disciplina deja de pagar

Sería deshonesto presentar la separación como gratuita. En una app de tres pantallas que consume una única API estable y que nunca tendrá modo sin conexión, la traducción de DTO a modelo duplica tipos casi idénticos y el protocolo añade un indirecto que nadie sustituirá jamás.

El criterio para saber si vale la pena tiene que ver con cuántos consumidores tiene el dato y con cuántas fuentes puede llegar a tener: una entidad leída por una sola pantalla y servida por un solo endpoint no necesita frontera, y una que alimenta la app, el widget y el reloj, y que debe funcionar sin conexión, la necesita desde el primer día.

Conviene además aplicar la separación por entidad y no por proyecto. Nada obliga a que todas las entidades de una app tengan el mismo grado de aduana: la que sostiene el negocio puede tener DTO, modelo, protocolo e implementación en memoria, mientras la que solo alimenta una pantalla de ayuda se decodifica directamente y se olvida. Esa asimetría deliberada es señal de criterio, no de descuido, y es lo que distingue una arquitectura pensada de una plantilla aplicada.