Arquitectura de Software

1

Arquitectura en Android

2

Patrón de diseño vs. Arquitectura de Diseño

3

¿Qué es la Arquitectura de Diseño?

4

SOLID: Single Responsability y Open/Closed Principles

5

SOLID: Liskov substitution, Interface segregation y Dependency Inversion principle

6

Evolución de la Arquitectura en Android

Arquitectura Model View Controller (MVC)

7

¿Qué es la aquitectura Model View Controller (MVC)?

8

MVC en un Proyecto Android: Analizando el código en capas

9

MVC en un Proyecto Android: Llevando el código a sus responsabilidades

Arquitectura Model View Presenter (MVP)

10

¿Qué es la aquitectura Model View Presenter (MVP)?

11

¿Qué es Clean Architecture?

12

Composición en Clases

13

Model View Presenter explicado

14

Capa Model

15

MVP en un Proyecto Android: Presenters y Views

16

MVP en un Proyecto Android: Model

17

Ubicando el código en MVP

Arquitectura Model View ViewModel (MVVM)

18

¿Qué es la arquitectura Model View ViewModel (MVVM)?

19

¿Cómo funciona MVVM Data Binding?

20

MVVM Data Binding estructurando nuestra aplicación y migrando a AndriodX

21

MVVM DataBinding creando un ViewModel

22

Patron Observer en MVVM

23

MVVM Data Binding: integrando ViewModel a View

24

MVVM Data Binding: RecyclerView Adapter

25

MVVM Data Binding: RecyclerView CardView

Android JetPack Arquitectura

26

¿Qué es Android JetPack Arquitectura?

27

¿Cómo funciona la arquitectura de componentes?

28

Arquitectura Componentes Lifecycle ViewModel

29

Arquitectura Componentes Lifecycle Observe

Fin del curso

30

Conclusiones

Curso de Arquitectura de Android

Curso de Arquitectura de Android

Anahí Salgado Díaz de la Vega

Anahí Salgado Díaz de la Vega

¿Qué es Clean Architecture?

11/30

Lectura

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.

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:

Fase 3_Template de Slides (1).png

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

Fase 3_Template de Slides.png

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

Fase 3_Template de Slides (3).png

Ahora, expliquemos cada elemento

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 7

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

SUPER RESUMEN CLEAN ARCHITECTURE
 Son las buenas practicas sobre un elemento en programación
Clean Code trata en referirse a que nuestro código sea más limpio y amplio
Clean Architecture separa el código en sus distintas responsabilidades, y se basa en los modelos de capa (Presentation layer, business Logic layer y Data Layer), creadas por el Tío Bob
.
Clean Architecture está basado en:

  1. La independencia de cualquier framework
  2. En Testeable, refiriéndose a las funciones puras (que retorna el mismo valor y no contiene nada que la altere como las variables globales) y la inmutabilidad (que contiene valores que nunca cambiaran). Cada Modulo debe ser testeado individualmente
  3. Independiente de la Interfaz de Usuario
  4. Independiente de la base de datos Permite manejar varias bases de datos: MySQL, PostgreSQL, Redis, etc.
  5. **Independiente de cualquier elemento externo. De hecho, para el sistema esta capa externa debería ser transparente.

Recordatorio de cada Elemento

  1. Entities, que son usadas en múltiples aplicaciones de negocio
  2. Use Cases (Casos de uso), orquestan las entidades
  3. Repositories y Presenters. Interface Adapters, convierte datos del usuario en beneficios.
  4. UI y Data Source. Frameworks y Drivers, detalles de la UI

Muy bueno el material de esta clase ayuda a entender como organizar nuestro còdigo de una forma mas eficiente

wow exelente explicacion… ese tio bob era todo un loquilo, yso un buen trabajo mas para aquellos que estamos iniciando el proceso de aprendizaje y dominio de las buenas practicas de la programacion… porque lo bonito es que son pricipios y practicas aplicables a cualqier entorno

Excelente, con respecto al principio 4. Independiente de la base de datos, creo que un buen ejemplo sería el caso de manejar las autenticaciones con Firebase, deberíamos tener desacoplado, de tal forma que si cambiamos de proveedor por ejemplo a AWS, solo se tenga que cambiar esa capa de DB, sin alterar toda nuestra aplicación.
Buena lectura 😃

Muy buena la información

Genial, se supone que debería aplicarse en todas sin problemas. ahora ya me dieron ganas de aprender las demás tecnologias para aprender su aplicación en las mismas

genial excelente explicación, debería de poder aplicarse en cualquier proyecto sin problemas