Visteme con 'Clean Architecture' que tengo prisas

Vísteme con ‘Clean
Architecture’ que
tengo prisas

¿Quién soy?
jmperezra@gmail.com
jmperezramos
http://jmperezramos.net
+JoseMariaPerezRamos
CHEMA

¡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.

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.

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.

¿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

2
Introducció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.

Presentadores
Controladores
● Comunica las
interfaces externas al
dominio con los casos
de uso.
● Adaptadores de datos
según la capa.

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.

Regla de Dependencia

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.

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.

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.

4
Arquitectura Clean aplicada al
proyecto
App 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

4
Definición de los módulos

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’

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
4
Capa ‘Presentation’

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.

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’

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.

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’

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.

4
Proyecto con Play Framework

5
Etapas 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

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.
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.
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.
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.
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.
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).

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.

Visteme con 'Clean Architecture' que tengo prisas

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Visteme con 'Clean Architecture' que tengo prisas

Similaire à Visteme con 'Clean Architecture' que tengo prisas (20)

Dernier

Dernier (6)

Visteme con 'Clean Architecture' que tengo prisas

Notes de l'éditeur