Introducción

1

Qué aprenderás sobre Clean Architecture en Android

2

¿Qué es clean architecture?

Repaso de Conceptos Generales

3

Principios SOLID

4

Repository Pattern

Presentación del proyecto

5

Presentación del proyecto: Rick and Morty

6

Uso de RxJava y RxAndroid en el proyecto

Capa de Presentación

7

Introducción a la capa de presentación

8

Implementación de la capa de presentación

9

Solución del reto

Capa de Casos de Uso

10

Introducción a la capa de casos de uso

11

Solución del reto: capa de casos de uso

Capa de Dominio

12

Introducción a la capa de dominio

13

Implementación de la capa de dominio: mappers

14

Migración entidades de framework a dominio

15

Solución del reto: capa de dominio

Capa de Datos

16

Introducción a la capa de datos

17

Implementación de la capa de datos: repositorio

18

Implementación de la capa de datos: fuente de datos

19

Solución del reto: capa de datos

Extras: Migración de Capa de Casos de Uso

20

Migración de la capa de casos de uso

Capa de Framework

21

Introducción a la capa de framework

22

Implementación de Image Manager (Glide)

23

Implementación de Database Manager (Room)

24

Implementación de Request Manager (Retrofit)

Inyección de Dependencias

25

Introducción a la inyección de dependencias

26

Implementación de Dagger (Módulos)

27

Implementación de Dagger (Componente)

28

Solución del reto: inyección de dependencias

Pruebas unitarias a nivel general

29

Implementación de pruebas unitarias (conceptos generales)

30

Pruebas unitarias en la capa de presentación

31

Pruebas unitarias en las capas de casos de uso y datos

Conclusiones

32

Cómo seguir mejorando la arquitectura

¿Qué es clean architecture?

2/32
Recursos

Los términos Clean Architecture y Clean Code hacen referencia a buenas prácticas de diseño de arquitectura y programación que se aplican sobre ciertos elementos.

  • Clean Architecture
  • Clean Code

Como parte de su filosofía, Clean Code busca que el código sea lo más limpio posible. Para lograrlo, existen recomendaciones que van desde cómo se nombran las variables, la forma como se construyen funciones o se comenta el código y la alineación o la abstracción de objetos y estructuras, entre otros.

Todo esto, con el fin de hacer el código mucho más entendible en el presente y futuro, testeable y fácil de integrar.

Qué es Clean Architecture

En esta ocasión hablaremos sobre Clean en la arquitectura de software, especialmente en Android.

El principal objetivo de una arquitectura limpia es la capacidad de separar el código en sus diferentes responsabilidades.

¿Recuerdas las 3 capas básicas del modelo de capas que presenté anteriormente?

  • Presentation Layer.
  • Business Logic Layer.
  • Data Layer.

Estas son las tres responsabilidades base sobre las cuales trabaja la arquitectura limpia.

Principios de la arquitectura limpia

Clean Architecture es un término introducido por Rober C. Martin, mejor conocido como Uncle Bob o Tío Bob. Él recopiló los modelos de capas más utilizados en una versión mejorada a la que llamó Clean Architecture.

A continuación, presento 5 principios sobre los cuales se basó:

1. Es independiente de cualquier framework

La arquitectura limpia debe ser capaz de aplicarse a cualquier sistema sin importar el lenguaje de programación o las librerías que utilice. Las capas deben quedar tan bien separadas que puedan sobrevivir individualmente, sin necesidad de externos.

2. Testeable

Entre más pura sea una función, clase o módulo más fácil será predecir el resultado a obtener. Cuando hablamos de que algo sea puro nos referimos a que no tenga efectos colaterales. Lee este artículo para que entiendas mucho más sobre los efectos colaterales y funciones puras. (Importante leerlo para completar la lección). Cada módulo, tanto de UI, base de datos, conexión a API Rest, etc., se debe poder testear de forma individual.

3. Independiente de la interfaz de usuario (UI)

Uno de los componentes que sufren cambios constantemente es la interfaz de usuario. La UI debe ser capaz de cambiar sin alterar todo el sistema y, si vamos más allá, esta capa debería vivir tan independiente que podría ser desensamblada y sustituida por otra. Por ejemplo, cambiar una UI Móvil por una en modo consola.

4. Independiente de la base de datos

Así como en el punto anterior, esta capa debe ser tan modular que sea posible agregarle múltiples fuentes de datos, e incluso múltiples fuentes del mismo tipo de datos. Por ejemplo, manejar varias bases de datos como MySQL, PostgreSQL, Redis, etc.

5. Independiente de cualquier elemento externo

Si en algún punto nuestro sistema necesita de una librería, otro sistema o cualquier elemento a conectar, debería ser fácilmente ensamblado y también debería ser modularizado. De hecho, para el sistema esta capa externa debería ser transparente.

Estos principios fueron graficados por el Tío Bob en el siguiente diagrama:

https://static.platzi.com/media/user_upload/Fase%203_Template%20de%20Slides%20%281%29-557994ef-9ce1-4929-8a69-aa0000bcefd8.jpg

Y si quisiéramos hacer encajar las tres capas que mencionamos antes, se vería así:

https://static.platzi.com/media/user_upload/Fase%203_Template%20de%20Slides-60bfec30-80ee-491e-b9b0-160de6814e07.jpg

El nivel de acceso se dará a partir de las capas externas hasta llegar a las internas, como se muestra a continuación:

https://static.platzi.com/media/user_upload/Fase%203_Template%20de%20Slides%20%283%29-f910bd6e-a024-4d24-b3bc-765db0db101d.jpg

Partes de una arquitectura limpia

En realidad nosotros en este punto ya tenemos experiencia con la separación de capas. De hecho, ya aplicamos dos arquitecturas: MVC y MVP. Para hacerlas Arquitectura Clean subdividiremos un poco más, pero eso lo veremos más adelante. Ahora, solo quiero explicarte cada elemento a manera de recordatorio:

1. Entities

Las entidades son los modelos definidos que interactuarán en el sistema. Estas deben ser lo suficientemente abstractas para ser usadas por múltiples aplicaciones en el negocio.

2. Use Cases (casos de uso)

Contienen las reglas que le dan sentido a la aplicación. Los casos de uso dirigen el flujo a las entidades y las orquestan para cumplir con el negocio.

3. Repositories y Presenters. Interface Adapters

Esta es la capa intercesora que convierte los datos extraídos por la interfaz de usuario y la capa de datos en el formato más conveniente para los casos de uso.

4. UI y Data Source. Frameworks y Drivers

En esta capa van todos los detalles, tanto para mostrar datos en la UI como para obtener los datos requeridos.

Como ves, hasta el momento nuestro proyecto ha tratado de seguir las reglas Clean Architecture. Estas tendrán sus propias variaciones, dependiendo de la arquitectura aplicada. Pero, en general, las que hemos mencionado son las pautas de una arquitectura limpia en el software.**

Aportes 6

Preguntas 1

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

The Clean Architecture

Surge de la necesidad de que muchos desarrolladores se encuentran con mucho código resolviendo muchos problemas, por ello nace Clean Arquitecture la idea se basa en centrarse en lo que tiene que hacer la aplicación como tal y y es por ello que dice que debemos de pensar en él framework como el mecanismo de paso de mensajes hacia nuestro software, el cual se debe mirar como una herramienta o plugin de lo que queremos realizar.

Antes de comenzar a describir los componentes importantes del esquema debes tener en cuenta que no es obligatorio ni mucho menos mandatorio usar solo 4 círculos ya que de acuerdo a Uncle Bob solo son esquemáticos y quizás tu problema necesita de más para poder ser resuelto.

Lo único que nos dice es que hay que respetar la Dependency Rule: “El código fuente sólo puede apuntar hacia adentro“.

Entities

Son aquellos objetos que van a representar los actores importantes de la lógica de negocio de nuestra aplicación.

Use Cases

Están muy relacionados con las entidades y son los encargados de implementar lógica de negocio de nuestra aplicación, ya que van a orientar todas aquellas interacciones del flujo de datos y entidades dejando al framework fuera de todo esto (en nuestro caso el sdk android), también se conocen como interactores.

(En ingeniería de software un caso de uso se define como: “Una secuencia de interacciones que se encargan de modelar alguna acción que quiero que mi software realice”)

Interface Adapters

Convierten los datos en el formato más conveniente para los casos de uso y entidades. (De manera recurrente aqui encontraras controladores y presentadores.)

Frameworks and Drivers

Aquí es donde residen los detalles y todo ese conjunto de plataformas externas y herramientas como puede ser la UI, Web, DB , Devices, etc. Generalmente solo se deben comunicar con el siguiente círculo a su interior.

Clean architecture te invita a cambiar el pensamiento y a construir tu solución de software desde adentro hacia afuera y no desde afuera hacia adentro.
Lo que ganas con ello es una mayor flexibilidad al cambio, incluso cambios robustos porque te da mucha libertad ya que no hay acoplamiento de la solución con el mundo exterior, entiéndase mundo exterior como (proveedores, servicios, base de datos, tipo de base de datos, librerías, frameworks, entre otros…) cosas que finalmente son triviales y no hacen parte de la responsabilidad del negocio de la aplicación, ya que esta se construye para modelar datos sin importar de dónde vengan.

Clean Architecture es un modelado para poder hacer nuestros proyectos por medio de capas, lo cual nos brinda mayor facilidad para que sea testeable y escalable, su implementación y la cantidad de capas a utilizar dependera del equipo de trabajo y lo que se desea lograr del proyecto.

Le dejo el diagrama de flujo

No puedo creer que este tomando un curso que fue creado hace más de 2 años!
Me encanta! Lo divertido de todo es que… ambos trabajamos en Globant, me gustaría en algún momento de la vida compartir algún proyecto contigo.