Características comunes de arquitecturas limpias

Características comunes:

• Dominio como elemento central.
• El dominio no depende de elementos externos.
• Las dependencias se invierten.
• Facilitan las pruebas (Testability).

Caracteristicas fundamentales en una arquitectura limpia.

segun el video menciono las cuatro caracteristicas:

1. Dominio como elemento central: En una arquitectura limpia, el dominio y la lógica de negocio son el corazón de la aplicación. Esto significa que todas las funcionalidades de la aplicación giran en torno a las reglas de negocio, que se encuentran en el centro de la arquitectura. Esto permite a los desarrolladores enfocarse en las reglas de negocio, que son las partes más críticas y valiosas de la aplicación

2. El dominio no depende de elementos externos.
el término “dominio” generalmente se refiere a la lógica de negocio de la aplicación, que son las reglas y comportamientos que definen cómo opera tu aplicación o sistema.

Cuando se dice que “El dominio no depende de elementos externos”, significa que la lógica de negocio de la aplicación no debe depender de detalles de infraestructura como la base de datos, la interfaz de usuario, los servicios de red, entre otros.

Se podría cambiar la base de datos de MySQL a PostgreSQL, cambiar la interfaz de usuario de una interfaz gráfica a una interfaz de línea de comandos, o cambiar tu protocolo de red de HTTP a WebSocket, y ninguna de estas modificaciones debería requerir que cambies la lógica de negocio de tu aplicación.

3. Las dependencias se invierten: las dependencias inversas permiten que el código sea más modular y más fácil de mantener y desarrollar. La lógica de negocio no depende directamente de las implementaciones de base de datos o de otros servicios. En su lugar, estos servicios se conectan a la lógica de negocio a través de interfaces o abstracciones, lo que facilita el cambio de una implementación por otra sin afectar la lógica de negocio.

4. Facilitan las pruebas (Testability): Dado que la lógica de negocio no está entrelazada con la lógica de la infraestructura (como la UI, la base de datos, etc.), es más fácil de probar. se pueden crear pruebas para la lógica de negocio sin tener que preocuparte por los detalles de la implementación de la infraestructura.

Las Arquitecturas limpias, muy bueno implementarla en proyectos nuevos,ya en proyectos que tienen un alto acoplamiento si hay que mirar bien que tanto y hasta donde vale la pena invertirle recursos y tiempo para hacerlo.

1. El dominio es el eje central del software. Por dominio se enciente la razón de ser del negocio, estas reglas son independientes de los componentes externos. 2. El dominio no depende de componentes externos. La lógica del negocio es independiente de otros factores. 3. Inversión de dependencias: A diferencia de las arquitecturas tradicionales, el dominio es completamente independiente y se basta por si mismo. 4. El dominio facilita el testeo, dado que no depende de nada.

Me estoy dando cuenta que no sé qué significa la lógica de negocio 😅

Característica 1: Dominio como elemento central

Toda arquitectura limpia gira en torno a un dominio.

El dominio es la razón de ser del sistema

El dominio existe o no exista la aplicación. Todo lo que es el core del negocio clasifica como dominio. Por ejemplo, tenemos un supermercado que quiere hacer su app, parte del dominio serían la funcionalidad de calcular descuentos o verificar inventario.

Son características que existen estén o no estén las aplicaciones.

Característica 2: El dominio no depende de elementos externos

¿Qué son los elementos externos en una aplicación limpia?

• Las interfaces gráficas no deberían de afectar a nuestro dominio
• Las bases de datos. Es un repositorio de información, no significa que puede cambiar con el tiempo o incluso decidir que no exista, porque querría decir que el negocio depende de esto.
• Sistemas de terceros. Por ejemplo, integraciones con red social. No son indispensables.
• Frameworks. Angular, React, Django, todos estos son considerados frameworks. Nuestra lógica de negocio no debe depender de estos.

Característica 3: Las dependencias se invierten

Vemos un contraste entre la arquitectura limpia y la de tres capas. Vemos que en la segunda hay una gran dependencia entre capas, presentación depende de dominio y dominio de acceso a datos.

En la primera esto cambio, la dependencia se invierte, el dominio ya no depende de acceso a datos sino que el acceso a datos va a depender del dominio.

![[Captura de pantalla 2023-09-18 a la(s) 21.43.11.png|300]]![[Captura de pantalla 2023-09-18 a la(s) 21.43.48.png|300]]

Característica 4: Facilitan las pruebas (testability)

Que tengamos separado el dominio de la capa externa, esa encapsulación justamente facilita la creación de pruebas al dominio, por ejemplo, puedo hacer pruebas al dominio sin tener la necesidad de configurar la capa externa.

Clase 3: Características comunes de arquitecturas limpias

Características

• El Dominio como elemento central -> Son los elementos que hacen el core del negocio.

En una arquitectura limpia, el dominio y la lógica de negocio son el corazón de la aplicación. 

Esto significa que todas las funcionalidades de la aplicación giran en torno a las reglas de negocio, que se 
encuentran en el centro de la arquitectura. 

Esto permite a los desarrolladores enfocarse en las reglas de negocio, que son las partes más críticas y valiosas de la aplicación

• El dominio no depende de elementos externos. -> Consideramos elementos externos las interfaces y la base de datos ya que no afectan a nuestro dominio.

Generalmente se refiere a la lógica de negocio de la aplicación, que son las reglas y comportamientos que definen cómo opera tu aplicación o sistema.

Cuando se dice que “El dominio no depende de elementos externos”, significa que la lógica de negocio de la aplicación no debe depender de detalles de infraestructura 
como la base de datos, la interfaz de usuario, los servicios de red, entre otros.

Se podría cambiar la base de datos de MySQL a PostgreSQL, cambiar la interfaz de usuario de una interfaz gráfica a una interfaz de línea de comandos, 
o cambiar tu protocolo de red de HTTP a WebSocket, y ninguna de estas modificaciones debería requerir que cambies la lógica de negocio de tu aplicación.

• Las dependencias se invierten -> Esto quiere decir que la capa mas externa va depender del dominio, aquí hay que imaginare que las capas con círculos y cada circulo exterior va depender del círculo mas interno que este es el dominio.

 las dependencias inversas permiten que el código sea más modular y más fácil de mantener y desarrollar. 
 La lógica de negocio no depende directamente de las implementaciones de base de datos o de otros servicios. 
 En su lugar, estos servicios se conectan a la lógica de negocio a través de interfaces o abstracciones, lo que facilita el 
 cambio de una implementación por otra sin afectar la lógica de negocio.

• Facilitan las pruebas (Testability). -> Al tener el dominio separada de la capa externa nos permite aislar y realizar testing mas eficiente

Dado que la lógica de negocio no está entrelazada con la lógica de la infraestructura 
(como la UI, la base de datos, etc.), es más fácil de probar. 
se pueden crear pruebas para la lógica de negocio sin tener que preocuparte por los detalles de la implementación de la infraestructura.

Es decir, manteniendo una base de datos fuera de lógica de negocio me impediría tener una implementación de store procedures?

Las características en la arquitectura limpia del desarrollo de software: consiste en la implementacion de distintas capas de tal manera que una no afecta el funcionamiento de las demás:

1. Independencia de los marcos de trabajo (Framework): Que esta no dependa de la existencia de alguna biblioteca especifica. Al aplicar este principio nos permite que nuestro sistema sea testeable.
2. Testeabilidad: Debe ser diseñada de tal manera que permita la realización tanto de pruebas unitarias como de integración.
3. Interfaz del usuario: Que esta pueda ser cambiada sin afectar el resto del sistema.
4. Independencia en la base de datos: Los detalles de la base de datos no deben ser relevantes a la hora de implementar la arquitectura limpia.
5. Independencia de cualquier agente externo: La arquitectura no debe depender de ningún agente externo.
   Entonces resumiendo las características de la arquitectura limpia, consiste básicamente en la separacion de responsabilidades, de tal manera que una no afecte a la Arquitectura en general, permitiendo asi que pueda ser testeable, escalable y mantenida a traves del tiempo, logrando una independencia independiente del tipo de tecnologia que se desea usar para esa app en especifico. Es importante que para el buen desarrollo de la arquitectura limpia, tambien es interesante tener conocimiento acerca del codigo limpio, ya que con este se lograra una facil comprension para el mantenimiento del software a traves del tiempo.
   Bibliografia
   Robert C. Martin, Clean Code, Clean architecture

Característica 4: Facilitan las pruebas (Testability). Al tener separado el dominio de la capa externa, pueden probarse ambas capas por separado, de forma aislada y con diferentes técnicas o herramientas.

Característica 3: Las dependencias se invierten. Tenemos 2 capas: Dominio (lógica de negocio) y Capa externa (elementos cambiantes). A diferencia de la arquitectura de 3 capas, en una arquitectura limpia, el acceso a datos dependerá del dominio.

Característica 2: El dominio (lógica de negocio) no depende de elementos externos. Los elementos externos son: - Interfaz gráfica. - Base de datos. Esta podría cambiar con el tiempo o eliminarse. - Sistemas de terceros. Incluye interacciones con redes sociales y otras aplicaciones desarrolladas por terceros. - Frameworks. El dominio es independiente de si se desarrolla el frontend con Angular, React, etc; el backend se desarrolla con .NET, Spring, etc. Podría incluso usarse una mixtura de frameworks.

Característica 1: Dominio como elemento central. En las Arquitecturas limpias, el dominio es la razón de ser del sistema. Este existirá independientemente de la existencia de la aplicación. El negocio debe seguir operando bajo las mismas reglas, sea cual sea la aplicación que se use para tal fin (incluso si se usa papel y lápiz).

Característica 1: Dominio como elemento central. En las Arquitecturas limpias, el dominio es la razón de ser del sistema. Este existirá independientemente de la existencia de la aplicación. El negocio debe seguir operando bajo las mismas reglas, sea cual sea la aplicación que se use para tal fin (incluso si se usa papel y lápiz).

✅

Al final no sé cómo se hará exactamente pero estoy seguro que no debe ser muy complicado. El paradigma POO dispone de muchas herramientas para ello. Soy optimista de que será más fácil de lo que se cree

Vengo por aqui solo por Manu Zapata, lovio dios de las arquitecturas

La separación entre el dominio y la capa externa me parece una excelente idea, puesto que nos permite no solamente tener una idea clara de qué existe en cada capa, sino escalar de una mejor manera una aplicación.

Si por ejemplo yo tengo mi sistema es una tienda en línea y para realizar los pagos necesito un sistema de tercero. ¿Entonces no puedo implementar una arquitectura limpia en ese caso? Dado que la lógica del negocio depende de que se pueda realizar la transacción y no la puedo separar.

Caracteristicas:

1. Dominio como elemento central
2. El dominio no depende de elementos externos
3. Las dependencias se invierten (Ejemplo modelo 3 capas, dependencias de arriba hacía abajo)
4. Facilitan las pruebas (Testability)

Sobre la separación de la capa de dominio de la capa externa opino que es una técnica muy conveniente para materializar de verdad las especificaciones de la lógica que el software debe respetar. Nos brinda la posibilidad de ser ágiles y flexibles al cambio. También podemos identificar más fácilmente la complejidad esencial (lógica que ya existe en el negocio/dominio) de la accidental (la que metemos nosotros y nuestras herramientas)

Qué tan difícil creo que puede llegar a ser implementarla? Pues es complicado al principio porque en la práctica llegamos a un punto en que tenemos que generar algún feature y no nos logramos hacer una idea de cómo resolver las cosas sin hacer lógica de dominio en un controlador de un servicio rest por ejemplo. Claro que hay maneras pero a veces no sabemos cómo.

Ah! y algo bien importante es que tenemos que tratar de entender bien la lógica y que nuestro equipo experto (product owner, o líderes) tengan la disposición de ayudarnos con las definiciones de las reglas de dominio. También entender que la “refactorización” es algo que tendremos que hacer constantemente conforme aprendemos nuevas cosas de la lógica del dominio o cuando la lógica (incluso del mundo real) cambia

Básicamente el Dominio es el eje central de las aplicaciones realizadas en arquitecturas limpias. El dominio son las reglas y lógica del negocio dichas reglas deben ser agnósticas de componentes externos (Bases de datos, Frameworks, Sistemas de terceros). Un ejemplo con la lógica de airbnb es que encontramos por ejemplo Reservas dichas reservas pueden tener ciertos atributos por ejemplo las persona que genera la reserva, el lugar asociado a la reserva, la cantidad de personas que asistirán a la reserva, etc… Pero también puede tener ciertas reglas como que las personas que asistan no supere el nivel que pueden tener el lugar o que por ejemplo que esa reserva no haga conflicto con otras reservas.

Ejemplo del objecto de dominio de reservas

Este podría tener por ejemplo algunas reglas de negocio como la de no hacer overbooking

Disclaimer este codigo puede tener typos 🙈