Principios de arquitectura en desarrollo móvil: qué son, tipos y cómo aplicarlos

Principios SOLID

Los principios de arquitectura son la base del código de calidad. SOLID es un acrónimo introducido por Robert Martin («Tío Bob») que describe cinco principios de diseño orientado a objetos. Seguir SOLID hace que el código sea más flexible, comprobable y resistente a los cambios. La violación de los principios de arquitectura es una de las principales causas de deuda técnica.

Examinemos cada principio. Single Responsibility Principle (SRP) — cada clase debe tener solo una razón para cambiar. Open/Closed Principle (OCP) — las clases están abiertas para extensión pero cerradas para modificación. Liskov Substitution Principle (LSP) — los objetos de subtipos deben reemplazar objetos de tipo base sin romper la lógica. Interface Segregation Principle (ISP) — muchos interfaces especializados son mejores que uno general. Dependency Inversion Principle (DIP) — depende de abstracciones, no de implementaciones concretas.

Según el análisis de SonarQube (2025), la violación de los principios SOLID ocurre en el 68% de los proyectos comerciales. Los problemas más comunes son la violación de SRP (35%) e ISP (22%). En IT Sectr, implementamos SOLID en la etapa de revisión de arquitectura — esto ayuda a identificar problemas antes de que se conviertan en deuda técnica.

Single Responsibility Principle (SRP)

SRP (Principio de Responsabilidad Única) — el más importante y al mismo tiempo el principio SOLID más frecuentemente violado. Establece: una clase debe tener solo una razón para cambiar. Si una clase hace demasiado, es difícil de probar, modificar y entender.

Una violación típica es una clase que simultáneamente procesa datos, los guarda en la base de datos y envía notificaciones por correo electrónico. El siguiente ejemplo muestra una violación de SRP en Kotlin y cómo corregirla.

// Violación SRP — la clase hace tres cosas diferentes
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validación de datos
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Guardar en base de datos
        val user = User(email, name)
        database.save(user)
        
        // 3. Enviar notificación
        emailService.sendWelcomeEmail(email, name)
    }
}

// Corrección — dividir en tres clases
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

En la versión corregida, cada clase es responsable de su propia tarea: UserValidator — de la validación, UserRepository — de guardar, NotificationService — de las notificaciones. Esto hace que el código sea comprobable y reutilizable — se puede reemplazar la implementación de la base de datos sin cambiar la lógica de validación.

GRASP y Ley de Demeter

GRASP (General Responsibility Assignment Software Patterns) — nueve principios de arquitectura para asignar responsabilidad entre objetos, descritos por Craig Larman. A diferencia de SOLID, GRASP responde a la pregunta «¿qué clase debería contener este método?». Patrones clave: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Ley de Demeter (LoD, principio de mínimo acoplamiento) — una regla simple: un objeto debe comunicarse solo con sus vecinos inmediatos. No se debe escribir a.getB().getC().doSomething() — esto crea un fuerte acoplamiento entre clases. LoD mejora la reutilización y simplifica las pruebas.

En IT Sectr, verificamos el cumplimiento de LoD durante las Revisiones de Código. Si un método «atraviesa» tres o más objetos, es una señal de que la arquitectura necesita simplificación. La violación de LoD es uno de los Code Smell más comunes en proyectos grandes.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) y YAGNI (You Ain't Gonna Need It) — tres principios básicos de arquitectura conocidos por todo desarrollador. A pesar de su simplicidad, las violaciones ocurren constantemente.

DRY — no duplique código. Si la misma lógica aparece en dos lugares, extráigala a un método o clase común. La duplicación es la principal fuente de errores: una corrección en un lugar se olvida de aplicarse en otro. DRY no significa que no pueda tener código similar — lo importante es que la lógica de negocio no se repita.

KISS — cuanto más simple, mejor. Las soluciones complejas con muchas abstracciones y herencias suelen ser excesivas. Comience con una solución simple y complíquela solo cuando sea necesario. YAGNI — no escriba código para funcionalidades que podrían necesitarse «algún día después». Esto lleva a la hinchazón de la base de código y aumenta la complejidad del mantenimiento.

DRY — Don't Repeat Yourself

DRY — no se trata solo de la ausencia de copia y pega. Es un principio según el cual cada pieza de conocimiento o lógica debe tener una representación única e inequívoca en el sistema. La duplicación puede ser explícita (código copiado) e implícita (misma lógica en diferentes capas).

En IT Sectr, utilizamos métricas de análisis de código para detectar duplicación. Herramientas como SonarQube y Detekt muestran el porcentaje de código duplicado. Un valor superior al 5% es motivo para refactorizar. Sin embargo, es importante recordar: DRY no debe lograrse a costa de abstracciones incorrectas — a veces es mejor dejar dos piezas de código similares como están si combinarlas complicaría la comprensión.

Separación de Intereses y Modularidad

Separación de Intereses (SoC) — un principio de arquitectura donde un sistema se divide en partes independientes (intereses), cada una resolviendo su propia tarea. Un ejemplo clásico es la separación en capas: presentación, lógica de negocio, acceso a datos. Cada capa depende solo de la capa inferior.

Modularidad — el grado en que un sistema puede dividirse en módulos. Un módulo es un grupo de clases lógicamente relacionadas con una interfaz bien definida. Los módulos deben estar débilmente acoplados (bajo acoplamiento) y fuertemente cohesionados (alta cohesión).

Cohesión vs Acoplamiento

Cohesión — una medida de cuánto los elementos dentro de un mismo módulo están relacionados entre sí. La alta cohesión es buena: una clase hace una cosa y la hace bien. Bajo acoplamiento — una medida de cuánto los módulos son independientes entre sí. El bajo acoplamiento es bueno: cambiar un módulo no rompe otros.

La arquitectura ideal es alta cohesión y bajo acoplamiento. En la práctica, esto significa: una clase contiene métodos que trabajan sobre los mismos datos (cohesión) y depende solo de abstracciones, no de implementaciones concretas (acoplamiento). Un desequilibrio lleva a «Objetos Dios» o «código espagueti».

Deuda técnica y Code Smell

Deuda técnica — una metáfora introducida por Ward Cunningham que describe los «intereses» que un equipo paga por decisiones de arquitectura subóptimas y la violación de principios de arquitectura. Como la deuda financiera, la deuda técnica puede ser intencional (decidimos hacerlo rápido, lo reharemos después) y no intencional (mala arquitectura por falta de experiencia).

Code Smell — signos superficiales de problemas profundos en el código. El término fue popularizado por Martin Fowler en el libro «Refactoring». Code Smell típicos: métodos largos, clases grandes, cadenas de llamadas largas, duplicación de código, uso excesivo de comentarios (en lugar de código claro).

En IT Sectr, la deuda técnica se rastrea en Jira como tareas separadas. Cada sprint, dedicamos el 20% del tiempo a la refactorización y el pago de la deuda. El trabajo sistemático con la deuda técnica es la única forma de evitar una situación en la que agregar una nueva funcionalidad lleve más tiempo que desarrollarla desde cero.