Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Vísteme con 'Clean Architecture' que tengo prisas.

Vísteme con 'Clean Architecture' que tengo prisas.

Jose Maria Pérez Ramos - La presentación es la experiencia de la aplicación de una Arquitectura Clean en un proyecto real (Inditex). Veremos las distintas fases y problemas por las que pasó el proyecto y cómo los fuimos resolviendo gracias a la arquitectura. Aunque el proyecto era para Android se podría aplicar a cualquier otro framework o lenguaje.

Betabeers Salamanca

February 24, 2016
Tweet

More Decks by Betabeers Salamanca

Other Decks in Technology

Transcript

  1. ¡Estamos contratando! Miguel Ángel Sánchez Vidales [email protected] • Departamento de

    Movilidad. • Desarrollo de aplicaciones móviles híbridas y nativas. • Aplicar buenas prácticas en los desarrollos: ◦ Arquitectura ◦ Testing • Objetivo: Crear un departamento referente en el área de movilidad dentro y fuera de Indra.
  2. Preparando el curso 2016/17 http://movilidad.usal.es • Dirigidos a graduados y

    profesionales que quieran especializar su perfil en el desarrollo de aplicaciones móviles. • Todas las plataformas actuales: Híbridas, Android, iOS y Windows Phone. • Modalidad Semi-presencial y Online. • Profesores profesionales en el sector. • Prácticas en empresas.
  3. Objetivos de la Charla • Compartir conocimientos (Betabeers). • Introducción

    a la Arquitectura Clean. • Beneficios de aplicar una arquitectura en el desarrollo de aplicaciones. • Arquitectura Clean en un proyecto real: ◦ Planificar las tareas según la situación del proyecto. ◦ Sacar el máximo provecho de los desarrolladores según su perfil. ◦ Etc.
  4. ¿Qué es una Arquitectura Software? Estructura de un Sistema compuesta

    de elementos* con propiedades visibles de forma externa y las relaciones que existen entre ellos. (Software Engineering Institute,SEI). *Definición abstracta: objetos, hilos, clases, componentes... 1
  5. ¿Qué NO es una Arquitectura Software? • Jerarquía de carpetas.

    Ej: paquetes en java. • MVC o MVP. El uso del patrón MVC o MVP no implica una arquitectura. • Estructura de un framework. Ej: Symfony, AngularJs, SDK Android, etc. 1
  6. “Architecture is about intent, not Frameworks.” 2 Rober C. Martin

    • Una arquitectura se centra en lo que hace la aplicación, no en el framework o librerías que usa. • El dominio o modelo de negocio (casos de uso y entidades) debe ser el núcleo la aplicación. • Base de datos, Servicios Web, Framework, librerías, User Interface, etc. no es relevante para el modelo de negocio.
  7. 2 Capas y dependencias Dominio o Modelo de Negocio •

    Lo más importante de la aplicación. • No depende de ninguna otra capa. • Formado por Casos de Usos (Interactors) y entidades.
  8. 2 Capas y dependencias Presentadores Controladores • Comunica las interfaces

    externas al dominio con los casos de uso. • Adaptadores de datos según la capa.
  9. 2 Capas y dependencias Interfaces Externas • Framework o librerías

    que se usan para el desarrollo de la aplicación. • Base de datos, Interfaz de Usuario, Servicios Web, etc.
  10. 2 Capas y dependencias Regla de Dependencia • Las dependencias

    a nivel de código fuente sólo pueden apuntar hacia dentro. • Una capa interna no puede usar elementos de una capa externa.
  11. El Proyecto: Inditex 3 Desarrollo de aplicaciones móviles para la

    gestiones diarias de artículos en las tiendas de la cadena Inditex. Estas gestiones pueden ser: • Control de stocks de artículos. • Pedidos de artículos. • Nuevas ofertas. • Etc.
  12. Contexto del Proyecto 3 • Desarrollo de una aplicación iOS

    y Android al mismo tiempo que se desarrollaban los servicios web. • Servicios Web con constantes cambios en los datos de entrada y/o salida. • El cliente entrega prototipos para que se use como funcional.
  13. Perfil desarrolladores Android 3 • Desarrollador A: Gran conocimiento de

    la UI en Android y Arquitectura Clean. • Desarrollador B: Gran conocimiento de la UI en Android y pocos conocimientos Arquitectura Clean. • Desarrollador C: Gran conocimiento de la UI en Android.
  14. El porqué de Arquitectura Clean 4 • Evolución constante de

    la aplicación con nuevas funcionalidades. • Desarrollo paralelo con los servicios web. • Requisitos: minimizar al máximo las incidencias. Desarrollar test. • Posibilidad de incluir desarrolladores no Android.
  15. Arquitectura y Estructura 4 En el módulo ‘domain’ se encuentra

    el modelo de negocio formado por: • Casos de usos. • Entidades Usaremos un Repository para la obtención de datos. Capa ‘Domain’
  16. Arquitectura y Estructura 4 En el módulo ‘domain’ se encuentra

    el modelo de negocio formado por: • Casos de usos. • Entidades Usaremos un Repository para la obtención de datos. Interfaz con la obtención de datos. Su concreción será implementada en data. Ej: void getUserById(int id); Capa ‘Domain’
  17. • En el módulo ‘presentation’ se encuentra el presentador que

    recibe peticiones del módulo android y ejecuta casos de uso. • Accede a la UI a través de una interfaz que es implementada por la vista. • Forma parte del patrón MVP. • Mappers de modelo de datos Arquitectura y Estructura 4 Capa ‘Presentation’
  18. MVP: Model View Presenter 4 Vista: MainActivity.class Presenter: MainPresenter.class *executeMockUseCase():

    ejecutaría un caso de uso de la capa de dominio y se recogería el resultado.
  19. Arquitectura y Estructura 4 En el módulo ‘android’ se encuentra

    todo el código dependiente del sdk android: actividades, fragmentos, adaptadores, inyección de dependencias, etc. Se crean modelo de datos adaptados a la Interfaz de Usuario. Capa ‘Android’
  20. Arquitectura y Estructura 4 Modelo de Datos de la Interfaz

    de Usuario • Clases que contienen atributos o métodos para obtener datos que necesita la vista. • En la vista no hay lógica, la vista mostrará datos con métodos simples: public String getTitle(); ◦ Si hay una fecha se pasará ya formateada. ◦ Si hay datos concatenados se pasará la cadena definitiva. Ej: 124.000 € ◦ Se evitará el pedir continuamente datos al dominio.
  21. Arquitectura y Estructura 4 • En el módulo ‘data’ se

    encuentra el código para la obtención de datos: base de datos, servicios web, ficheros. • Tiene dependencia con el sdk Android. Se crean modelo de datos adaptados a la Base de datos o API. Capa ‘Data’
  22. Arquitectura y Estructura 4 Modelo de Datos para la capa

    ‘Data’ • Se crea un modelo de datos para el envío y recepción de datos. Se usarán anotaciones Gson. • Se crea un modelo de datos para trabajar con base de datos. Se usarán anotaciones de GreenDAO. • Al usar anotaciones particulares de una librería es conveniente usar modelos de datos específicos para evitar “acoplar” las entidades a estas librerías.
  23. Etapa 1ª: “No llegamos” • La fecha de entrega del

    prototipo ‘funcional’ está cerca. • Prototipo bien definido en esta primera entrega. • Cambios constantes en la API. • Se permite trabajar con mocks. • Prioridad: Desarrollar la interfaz de usuario. Diseño de la Interfaz de Usuario ‘definitivo’. • No desarrollar la capa de datos (API) y trabajar con mocks. Context Tareas 5.1
  24. Etapa 1ª: “No llegamos” • La fecha de entrega del

    prototipo ‘funcional’ está cerca. • Prototipo bien definido en esta primera entrega. • Cambios constantes en la API. • Se permite trabajar con mocks. • Prioridad: Desarrollar la interfaz de usuario. Diseño de la Interfaz de Usuario ‘definitivo’. • No desarrollar la capa de datos (API) y trabajar con mocks. Context Tareas 5.1
  25. Etapa 1ª: “No llegamos” • La fecha de entrega del

    prototipo ‘funcional’ está cerca. • Prototipo bien definido en esta primera entrega. • Cambios constantes en la API. • Se permite trabajar con mocks. • Prioridad: Desarrollar la interfaz de usuario. Diseño de la Interfaz de Usuario ‘definitivo’. • No desarrollar la capa de datos (API) y trabajar con mocks. Context Tareas 5.1
  26. Etapa 1ª: “No llegamos” • La fecha de entrega del

    prototipo ‘funcional’ está cerca. • Prototipo bien definido en esta primera entrega. • Cambios constantes en la API. • Se permite trabajar con mocks. • Prioridad: Desarrollar la interfaz de usuario. Diseño de la Interfaz de Usuario ‘definitivo’. • No desarrollar la capa de datos (API) y trabajar con mocks. Context Tareas 5.1
  27. Resultado Obtenido: • Definición de la Arquitectura y sus capas.

    • Definición de librerías de terceros: ◦ Butterknife ◦ Dagger ◦ Test ◦ Retrofit ◦ OkHttp • Capas a desarrollar: android y presentation. Etapa 1ª: “No llegamos” 5.1
  28. Dos desarrolladores Android con gran conocimientos de la UI. Desarrollador

    Android con gran conocimientos de la UI y arquitectura. Capa Android: UI Context Tareas Capa Presentación. Mocks para la vista. Etapa 2ª: “¡Empecemos! ¿Qué hago yo?” 5.2
  29. • Se definen los presentadores y devuelven modelos de datos

    exclusivos para la UI con datos fake. • Un desarrollador trabajando en esta capa. Etapa 2ª: “¡Empecemos! ¿Qué hago yo?” 5.2
  30. • Se implementa la Interfaz de Usuario (UI). • La

    UI recibe del presentador un modelo de datos que cumple con todas las necesidades de la UI. • Dos desarrolladores trabajando en esta capa. Etapa 2ª: “¡Empecemos! ¿Qué hago yo?” 5.2
  31. Resultado Obtenido: • Interfaz de Usuario desarrollada. ◦ Aspecto visual

    completado. ◦ Los modelos que reciben la interfaz de usuario son definitivo aunque se crean a través de datos Fakes. • Se cumple el objetivo de tener la aplicación funcional con mocks (permitido). • No somos bloqueados por otros desarrollos. Ej: Servicios Web. Etapa 2ª: “¡Empecemos! ¿Qué hago yo?” 5.2
  32. • Se definen las entidades y casos de uso de

    la aplicación. • Se usan mocks para la obtención de datos desde la API o Base de datos. • Un desarrollador. Etapa 3ª: “Primer matchball salvado” 5.3
  33. • Se quitan los datos fakes de la capa ‘presentation’

    y se ejecutan los casos de uso de la capa ‘domain’. • Se crean los mappers entidad- modeloUI y modeloUI-entidad. • Un desarrollador. Etapa 3ª: “Primer matchball salvado” 5.3
  34. Resultado Obtenido: • Se implementa la capa presentación. ◦ Interacción

    con los Casos de Uso. ◦ Creación de mappers. ◦ Se eliminan los datos fakes. • Se implementa la capa de dominio. ◦ Se corrigen posibles errores en la obtención de datos para la UI. ◦ Se definen las abstracciones para la obtención de datos. Etapa 3ª: “Primer matchball salvado” 5.3
  35. • Se quitan los mocks de la capa data y

    se implementa la obtención de datos de la API y de Base de datos. • Se usa un cliente de acceso a la API que consume ficheros json locales. • Dos desarrolladores. Etapa 4ª: “Web Services acabados” 5.4
  36. Resultado Obtenido: • Se implementa la capa data. ◦ Se

    define la obtención de datos de la API. ▪ Se crean modelos exclusivos para la API para el envío y recepción de información. ▪ Los mocks son JSON obtenidos de forma local (evitar depender de una conexión a red) ◦ Se define la obtención de datos locales. ▪ Se crean modelos exclusivos para las operaciones con SqLite (GreenDAO-ORM). Etapa 4ª: “Web Services acabados” 5.4
  37. • Se apunta al servidor de desarrollo y se prueba

    con conexión a internet. Etapa 5ª (Final): “Integrando todo” 5.5
  38. Etapa 5ª (Final): “Integrando todo” 5.5 • Se ejecutan los

    test y se refactoriza si es necesario. • Se elimina cualquier deuda técnica detectada (ToDo).
  39. Conclusiones 6.1 • La definición de la arquitectura, integración con

    librerías, inyección de dependencias, etc. hace que el inicio sea lento. Recomendación: crear un proyecto con todo esto definido y que sea la base de futuros proyectos. • Al estar las funcionalidades distribuidas por capas, se crea la sensación de no encontrar el código o de estar perdido. • El trabajar con capas te aísla de problemas que afectan a otras capas.
  40. Conclusiones 6.2 • El trabajar con abstracciones permite que el

    proyecto sea más flexible ante cambios. • Reutilización de código. Toda la lógica está centrada en la capa de dominio que es accesible desde cualquier otra capa. • Código testeable. No hay código acoplado que no permita falsear ciertos datos para comprobar distintos comportamientos.