No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Caracter铆sticas comunes de arquitecturas limpias

3/24
Recursos

Aportes 22

Preguntas 3

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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 鈥渄ominio鈥 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 鈥淓l 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 鈥淓l 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 鈥渞efactorizaci贸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 馃檲