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 aplica...
Preparando el curso 2016/17
http://movilidad.usal.es
● Dirigidos a graduados y profesionales que quieran especializar su p...
Objetivos de la Charla
● Compartir conocimientos (Betabeers).
● Introducción a la Arquitectura Clean.
● Beneficios de apli...
1
Arquitectura del Software
¿Qué es una Arquitectura Software?
Estructura de un Sistema compuesta de elementos* con propiedades visibles de
forma exte...
¿Qué NO es una Arquitectura
Software?
● Jerarquía de carpetas. Ej: paquetes en java.
● MVC o MVP. El uso del patrón MVC o ...
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ó...
2Capas y dependencias
Dominio o Modelo de
Negocio
● Lo más importante de
la aplicación.
● No depende de
ninguna otra capa....
2Capas y dependencias
Presentadores
Controladores
● Comunica las
interfaces externas al
dominio con los casos
de uso.
● Ad...
2Capas y dependencias
Interfaces Externas
● Framework o librerías
que se usan para el
desarrollo de la
aplicación.
● Base ...
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.
●...
3
Proyecto Inditex
Por Indra
El Proyecto: Inditex
3
Desarrollo de aplicaciones móviles para la gestiones diarias de artículos en las
tiendas de la cade...
El Proyecto: Inditex
3
Contexto del Proyecto
3
● Desarrollo de una aplicación iOS y Android al mismo tiempo que se
desarrollaban los servicios we...
Perfil desarrolladores Android
3
● Desarrollador A: Gran conocimiento de la UI en Android y Arquitectura
Clean.
● Desarrol...
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...
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.
● Entida...
Arquitectura y Estructura
4
En el módulo ‘domain’ se encuentra el modelo
de negocio formado por:
● Casos de usos.
● Entida...
Domain: Threads 4
MockInterctor.classMockPresenter.class
executeCUMock()
Main(UI)
Thread
obtainMockData()
MockDataSource.c...
● En el módulo ‘presentation’ se encuentra el
presentador que recibe peticiones del
módulo android y ejecuta casos de uso....
MVP: Model View Presenter 4
Vista: MainActivity.class Presenter: MainPresenter.class
*executeMockUseCase():
ejecutaría un ...
Arquitectura y Estructura
4
En el módulo ‘android’ se encuentra todo el
código dependiente del sdk android:
actividades, f...
Arquitectura y Estructura
4
Modelo de Datos de la Interfaz de Usuario
● Clases que contienen atributos o métodos para obte...
Arquitectura y Estructura
4
● En el módulo ‘data’ se encuentra el código
para la obtención de datos: base de datos,
servic...
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 ...
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Arquitectura y Estructura
4
Arquitectura y Estructura
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
prim...
Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
prim...
Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
prim...
Etapa 1ª: “No llegamos”
● La fecha de entrega del prototipo
‘funcional’ está cerca.
● Prototipo bien definido en esta
prim...
Resultado Obtenido:
● Definición de la Arquitectura y sus capas.
● Definición de librerías de terceros:
○ Butterknife
○ Da...
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
arqui...
● Se definen los presentadores y
devuelven modelos de datos
exclusivos para la UI con datos fake.
● Un desarrollador traba...
● Se implementa la Interfaz de Usuario
(UI).
● La UI recibe del presentador un modelo
de datos que cumple con todas las
ne...
Resultado Obtenido:
● Interfaz de Usuario desarrollada.
○ Aspecto visual completado.
○ Los modelos que reciben la interfaz...
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...
● Se quitan los datos fakes de la capa
‘presentation’ y se ejecutan los casos
de uso de la capa ‘domain’.
● Se crean los m...
Resultado Obtenido:
● Se implementa la capa presentación.
○ Interacción con los Casos de Uso.
○ Creación de mappers.
○ Se ...
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 clie...
Resultado Obtenido:
● Se implementa la capa data.
○ Se define la obtención de datos de la API.
■ Se crean modelos exclusiv...
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 de...
6
Conclusiones
por Chema
Conclusiones
6.1
● La definición de la arquitectura, integración con librerías, inyección de
dependencias, etc. hace que e...
Conclusiones
6.2
● El trabajar con abstracciones permite que el proyecto sea más flexible ante
cambios.
● Reutilización de...
¡Gracias!
¿Preguntas?
Fin
Próxima SlideShare
Cargando en…5
×

Visteme con 'Clean Architecture' que tengo prisas

2.822 visualizaciones

Publicado el

Presentación que tiene como objetivo la aplicación de Clean Architecture en un proyecto real. Se usa como ejemplo Android.

Publicado en: Software
0 comentarios
3 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
2.822
En SlideShare
0
De insertados
0
Número de insertados
1.971
Acciones
Compartido
0
Descargas
33
Comentarios
0
Recomendaciones
3
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Una arquitectura se base en intenciones, no en Frameworks.
  • Visteme con 'Clean Architecture' que tengo prisas

    1. 1. Vísteme con ‘Clean Architecture’ que tengo prisas
    2. 2. ¿Quién soy? jmperezra@gmail.com jmperezramos http://jmperezramos.net +JoseMariaPerezRamos CHEMA
    3. 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. 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. 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.
    6. 6. 1 Arquitectura del Software
    7. 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. 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
    9. 9. 2 Introducción a la Arquitectura Clean De Uncle Bob, 2012
    10. 10. “Architecture is about intent, not Frameworks.” Rober C. Martin 2
    11. 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. 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.
    13. 13. 2Capas y dependencias Presentadores Controladores ● Comunica las interfaces externas al dominio con los casos de uso. ● Adaptadores de datos según la capa.
    14. 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.
    15. 15. 2Capas y dependencias Regla de Dependencia
    16. 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.
    17. 17. 3 Proyecto Inditex Por Indra
    18. 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.
    19. 19. El Proyecto: Inditex 3
    20. 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. 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.
    22. 22. 4 Arquitectura Clean aplicada al proyecto App Android Inditex
    23. 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.
    24. 24. Arquitectura y Estructura 4 Módulos de la aplicación
    25. 25. Arquitectura y Estructura 4
    26. 26. Arquitectura y Estructura 4 Definición de los módulos
    27. 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. 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’
    29. 29. Domain: Threads 4 MockInterctor.classMockPresenter.class executeCUMock() Main(UI) Thread obtainMockData() MockDataSource.class Back Thread callbackCUMock() Main(UI) Thread synchronous
    30. 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. 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. 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. 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. 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. 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.
    36. 36. Arquitectura y Estructura 4
    37. 37. Arquitectura y Estructura 4
    38. 38. Arquitectura y Estructura 4
    39. 39. Arquitectura y Estructura 4 Proyecto con Play Framework
    40. 40. 5 Etapas del proyecto App Android Inditex
    41. 41. Etapa 1: “No llegamos” No hemos empezado y ya vamos con retrasos. 5.1
    42. 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. 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. 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. 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. 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
    47. 47. Etapa 2ª “¡Empecemos! ¿qué hago yo?” 5.2
    48. 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. 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. 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. 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
    52. 52. Etapa 3ª “Primer Matchball salvado” Después de la primera entrega, llega la tranquilidad. 5.3
    53. 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. 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. 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
    56. 56. Etapa 4ª “Web Services acabados” 5.4
    57. 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. 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
    59. 59. Etapa 5ª “Integrando todo” 5.5
    60. 60. ● Se apunta al servidor de desarrollo y se prueba con conexión a internet. Etapa 5ª (Final): “Integrando todo” 5.5
    61. 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).
    62. 62. 6 Conclusiones por Chema
    63. 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. 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.
    65. 65. ¡Gracias! ¿Preguntas? Fin

    ×