Embed Size (px)
Citation preview
Vísteme con ‘Clean Architecture’ que tengo prisas
¡Estamos contratando!Miguel Ángel Sánchez Vidales
● 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.
Preparando el curso 2016/17http://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.
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.
1Arquitectura del Software
¿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
¿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
2Introducción a la Arquitectura Clean
De Uncle Bob, 2012
“Architecture is about intent,
not Frameworks.”
Rober C. Martin
2
“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.
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.
2Capas y dependencias
Presentadores
Controladores
● Comunica las
interfaces
externas al
dominio con los
casos de uso.
● Adaptadores de
datos según la
capa.
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.
2Capas y dependencias
Regla de
Dependencia
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.
3Proyecto Inditex
Por Indra
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.
El Proyecto: Inditex3
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.
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.
4Arquitectura Clean
aplicada al proyectoApp Android Inditex
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.
Arquitectura y Estructura
4
Módulos de la aplicación
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Definición de los módulos
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’
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’
Domain: Threads 4
MockInterctor.classMockPresenter.class
executeCUMock()
Main(UI) Thread
obtainMockData()
MockDataSource.class
Back Thread
callbackCUMock() Main(UI) Thread
synchronous
● 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’
MVP: Model View Presenter 4Vista: MainActivity.class Presenter: MainPresenter.class
*executeMockUseCase(): ejecutaría un caso de uso de la capa de dominio y se recogería el resultado.
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’
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.
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’
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.
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Proyecto con Play Framework
5Etapas del proyecto
App Android Inditex
Etapa 1: “No llegamos”
No hemos empezado y ya vamos
con retrasos.
5.1
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
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
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
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
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
Etapa 2ª
“¡Empecemos! ¿qué hago yo?”
5.2
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
● 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
● 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
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
Etapa 3ª
“Primer Matchball salvado”
Después de la primera entrega,
llega la tranquilidad.
5.3
● 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
● 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
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
Etapa 4ª
“Web Services acabados”
5.4
● 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
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
Etapa 5ª
“Integrando todo”
5.5
● Se apunta al servidor de
desarrollo y se prueba con
conexión a internet.
Etapa 5ª (Final): “Integrando todo”
5.5
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).
6Conclusiones
por Chema
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.
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.
¡Gracias!¿Preguntas?
Fin
