SoC en el desarrollo móvil: qué es, principios y separación de responsabilidades

Qué significa la abreviatura SoC

SoC significa Separation of Concerns — «separación de responsabilidades» o «separación de áreas de interés». En el contexto del desarrollo, el término concern designa cualquier funcionalidad separable: representación de la interfaz de usuario, manejo de clics, validación de datos, comunicación en red o trabajo con la base de datos. El principio SoC prescribe agrupar el código en torno a estas áreas para que los cambios en una no afecten a las demás.

La abreviatura SoC se utiliza ampliamente en la literatura técnica, discusiones arquitectónicas y documentación de frameworks. Por ejemplo, en la documentación de Android Architecture Components, se menciona SoC repetidamente como motivación para separar ViewModel y View. En la comunidad iOS, el término se usa al discutir el problema de Massive View Controller, consecuencia directa de la ausencia de SoC.

Es importante entender que SoC no es una acción única, sino un proceso continuo. A medida que la aplicación crece, surgen nuevas áreas de responsabilidad y la arquitectura debe revisarse. Una buena base de código pasa por varias iteraciones de separación antes de alcanzar un estado estable donde cada concern esté aislado y gestionable.

SoC vs Separation of Concerns

Separation of Concerns y su abreviatura SoC designan el mismo principio. La única diferencia está en el contexto de uso: el nombre completo se emplea en documentos formales, materiales educativos y al explicar el concepto por primera vez a nuevos desarrolladores. SoC es cómodo en discusiones técnicas, revisiones de código y documentación donde la brevedad importa.

En el entorno profesional, ambos términos son intercambiables. Un desarrollador puede decir «aquí se viola SoC» o «esto viola Separation of Concerns»: el significado no cambia. Sin embargo, en las ofertas de empleo y requisitos de arquitectura se usa más a menudo el nombre completo, mientras que en chats y revisiones de código se emplea la abreviatura. Conocer ambas variantes es necesario para una entrada cómoda en la industria.

Existe confusión terminológica: la abreviatura SoC también se usa en el contexto hardware para System-on-a-Chip (sistema en un chip). En el desarrollo móvil, el contexto siempre está claro por el entorno: si la discusión trata sobre arquitectura de código, se refiere a Separation of Concerns. En este artículo, SoC se refiere siempre al principio de separación de responsabilidades.

Cómo se aplica SoC en la arquitectura móvil

La arquitectura de tres capas es la forma más común de implementar SoC en aplicaciones móviles. Divide el código en Presentation (UI), Domain (lógica de negocio) y Data (fuentes de datos). Cada capa contiene tipos de clases estrictamente definidos y está aislada de las vecinas mediante interfaces. Este enfoque es igualmente eficaz para proyectos iOS, Android y Flutter.

Capa de Presentation y ViewModel

View y ViewModel forman la capa de presentación. View se encarga de renderizar la interfaz y transmitir los eventos del usuario. ViewModel almacena el estado de la pantalla y transforma los datos de la capa Domain a un formato listo para mostrar. ViewModel no tiene referencias a Activity, Fragment ni UIViewController: esto garantiza SoC entre la UI y la lógica.

Por ejemplo, en Android Jetpack, ViewModel sobrevive a la rotación de pantalla mientras que la UI se recrea. Sin SoC, habría que guardar el estado en Activity, mezclando la gestión del ciclo de vida con los datos. ViewModel resuelve este problema de forma aislada, demostrando una implementación limpia del principio de separación de responsabilidades.

Capa de Domain y Use Cases

Los Use Cases contienen reglas de negocio independientes de la plataforma. Esta capa no importa Android SDK, iOS UIKit ni Flutter framework. Un Use Case recibe datos del Repository, aplica lógica de negocio y devuelve el resultado. Gracias a SoC, un mismo Use Case puede reutilizarse en diferentes pantallas y plataformas.

Un ejemplo clásico es el ValidateAndSaveUseCase para un formulario de registro. Valida el correo electrónico y la contraseña, llama al UserRepository para guardar y devuelve un ValidationResult. Ni la UI ni la base de datos conocen las reglas de validación: están concentradas en un solo lugar, lo que facilita su modificación.

Capa de Data y Repository

El Repository abstrae las fuentes de datos del resto de la aplicación. ViewModel no sabe de dónde provienen los datos — si de REST API, GraphQL, base de datos local o caché. El Repository decide qué fuente usar y oculta esta lógica tras una interfaz. Esto es SoC entre la obtención de datos y su consumo.

DataSource proporciona una separación aún más profunda: RemoteDataSource se encarga solo de las peticiones HTTP, LocalDataSource del trabajo con Room, CoreData o SharedPreferences. El Repository las combina aplicando estrategias de caché. Cada DataSource puede reemplazarse de forma independiente, lo que es crítico al migrar entre servidores o bases de datos.

Este sistema multinivel de DataSource implementa SoC a nivel de infraestructura: la comunicación en red, el almacenamiento local y el caché son concerns separados, cada uno con su propia lógica y ciclo de vida. Al reemplazar un cliente HTTP, solo cambia RemoteDataSource, mientras que el Repository y las capas superiores permanecen intactos, confirmando el valor práctico de la separación de responsabilidades.

SoC en los patrones arquitectónicos

MVP (Model-View-Presenter) fue uno de los primeros patrones que implementaron explícitamente SoC en el desarrollo móvil. El Presenter contiene la lógica y controla la View a través de una interfaz. La View es pasiva: solo muestra lo que el Presenter le indica. La separación simplifica las pruebas: el Presenter se prueba sin emulador y la View permanece tan simple que no hay nada que romper.

MVVM añadió el enlace reactivo: la View se suscribe a los cambios de ViewModel mediante Observable o StateFlow. ViewModel no guarda referencia a la View, lo que elimina el riesgo de fugas de memoria y separa aún más los concerns. En Android, MVVM se convirtió en el estándar gracias a Jetpack ViewModel y LiveData; en iOS, gracias a Combine y RxSwift.

Clean Architecture de Robert Martin lleva SoC a una separación radical en anillos. El anillo exterior (frameworks y controladores) depende del interior (entidades), pero no al revés. En la práctica, los proyectos móviles rara vez implementan los cuatro anillos: basta con las capas Domain y Data alrededor de Presentation. Pero el principio de «dependencia hacia dentro» ofrece ventajas significativas al cambiar de frameworks.

// View — solo visualización, sin lógica
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — contiene la lógica de la pantalla, no conoce UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — lógica de negocio, independiente de la plataforma
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

El ejemplo muestra tres niveles de SoC: LoginViewController solo transmite eventos, LoginViewModel gestiona el estado y LoginUseCase contiene las reglas de negocio. Cada clase se prueba de forma independiente y el cambio del framework de UI no afecta al Use Case.

Violaciones típicas de SoC en proyectos móviles

Massive View Controller es la violación más frecuente de SoC en iOS. Una clase que gestiona la UI, maneja peticiones de red, analiza JSON y persiste datos viola el principio en todos los niveles. La solución es extraer cada responsabilidad en un componente separado: NetworkingService, JSONParser, CoreDataStack, dejando al ViewController solo la gestión de la View.

En Android, un problema similar es God Activity o God Fragment. Una actividad que carga datos, valida formularios, muestra diálogos y actualiza la UI. Se soluciona introduciendo ViewModel y Repository, que asumen la gestión del estado y los datos. ViewModel también protege contra la pérdida de datos durante la rotación de pantalla.

La tercera violación es mezclar código de plataforma y de negocio. Por ejemplo, colocar una petición HTTP directamente en una SwiftUI View o Android Composable. Esto hace que el código no sea portátil y difícil de probar. El enfoque correcto es trasladar la petición a un Repository, que se invoca a través de un Use Case, mientras que la View solo se suscribe al resultado. Cada elemento del sistema resuelve su propia tarea y no sobrepasa sus límites.