3. ¡Estamos contratando!
Miguel Ángel Sánchez Vidales
masanchezv@indra.es
● 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.
4. 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.
5. 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.
7. ¿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
8. ¿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
11. “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.
12. 2Capas 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.
14. 2Capas 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.
16. 2Capas 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.
18. 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.
20. 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.
21. 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.
23. 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.
27. 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’
28. 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’
30. ● 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’
31. 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.
32. 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’
33. 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.
34. 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’
35. 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.
41. Etapa 1: “No llegamos”
No hemos empezado y ya vamos con
retrasos.
5.1
42. 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
43. 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
44. 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
45. 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
46. 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
48. 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
49. ● 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
50. ● 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
51. 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
53. ● 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
54. ● 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
55. 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
57. ● 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
58. 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
60. ● Se apunta al servidor de desarrollo y
se prueba con conexión a internet.
Etapa 5ª (Final): “Integrando todo”
5.5
61. 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).
63. 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.
64. 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.