Introducci贸n al curso

1

Introducci贸n al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definici贸n

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecuci贸n

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monol铆ticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisi贸n de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Dise帽o orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Dise帽o de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un dise帽o: Tipos de conectores

27

Conectores: Llamado asincr贸nico / sincr贸nico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusi贸n

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y t谩cticas

31

Escenarios: Disponibilidad, detecci贸n, reparaci贸n

32

Escenarios: Reintroducci贸n y prevenci贸n

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos domin贸 y diferir enlace

35

Escenarios: Eficiencia de ejecuci贸n

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de dise帽o: Arquitectura en evoluci贸n

40

脷ltimo an谩lisis a PlatziServicios

Modelado y documentaci贸n de arquitectura

41

C贸mo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentaci贸n vs implementaci贸n

43

Conclusiones del curso

No tienes acceso a esta clase

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

Patrones: Hexagonal - Puertos y adaptadores

21/43
Recursos

Tambi茅n conocido como puertos y adaptadores.

Aportes 14

Preguntas 7

Ordenar por:

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

  • La Arquitectura Hexagonal propone que nuestro dominio sea el n煤cleo de las capas y que este no se acople a nada externo. En lugar de hacer uso expl铆cito y mediante el principio de inversi贸n de dependencias nos acoplamos a contratos (interfaces o puertos) y no a implementaciones concretas.
  • A grandes rasgos, y si mucho detalle, lo que propone es que nuestro n煤cleo sea visto como una API con unos contratos bien especificados. Definiendo puertos o puntos de entrada e interfaces (adaptadores) para que otros m贸dulos (UI, BBDD, Test) puedan implementarlas y comunicarse con la capa de negocio sin que 茅sta deba saber el origen de la conexi贸n.

Hexagonal - Puertos y adaptadores

Nos ayuda a dise帽ar una aplicaci贸n que tenga bien claras cu谩les son sus dependencias externas, es decir, c贸mo se va a consumir externamente y qu茅 necesita del mundo exterior. Esto lo hace definiendo puertos que son su capa fina de comunicaci贸n con el exterior en d贸nde la aplicaci贸n s贸lo sabe su funcionalidad, pero no el c贸mo, y adaptadores que se van a encargar del c贸mo espec铆ficamente

Est谩 bien la teor铆a pero hubiese estado mucho mejor haber llevado esto a clases en un framework mvc.

Con toda esta informaci贸n no se como plasmarlo en mi c贸digo php

Patr贸n de arquitectura hexagonal / Puertos y adaptadores
Ayuda a dise帽ar una aplicaci贸n con dependencias externas claras.
Define puertos que son la capa fin con el exterior. La aplicaci贸n solo sabe su funcionalidad pero no el como y los adaptadores se encargan del como espec铆ficamente.
Ejemplo: Aplicaci贸n web

Patrones: Hexagonal - Puertos y adaptadores

Nos ayuda a construir un patron que tiene bien claras sus dependencias externas. Esto lo hace definiendo puertos que son su capa fina con el exterior, donde la aplicaci贸n sabe su funcionalidad pero no el como. Y existen adaptares que se encargar谩n del 鈥淐omo鈥 especificamente.


Si la App necesita acceso al file system o a la BD va a modelar un puerto que represente a sus datos y luego va a modelar un adaptador. Esta aplicaci贸n permite hacer tests de unidades muy f谩cilmente.


Ejemplos: Aplicaciones WEB

en mi opini贸n, esto es mas de lo mismo solo que con nombres rinbombantes鈥 en si aplicando meyer/liskov + solid + mvc podes llegar a un buen dise帽o de arquitectura. De echo en el libro mismo dice que el hexagono no tiene un proposito solo fue una elecci贸n para que le quede libre las caras de up y down. Pero bueno es mi opini贸n鈥

Ayuda a dise帽ar una aplicaci贸n con dependencias externas claras.

馃
La Arquitectura Hexagonal propone que nuestro dominio sea el n煤cleo de las capas y que este no se acople a nada externo. En lugar de hacer uso expl铆cito y mediante el principio de inversi贸n de dependencias nos acoplamos a contratos (interfaces o puertos) y no a implementaciones concretas.

Hola estos son un ejemplo de scaffolding que me parecieron interesantes (spring boot) usando este tipo de arquitectura hexagonal:

application/
rest/ # el controller
request/ # aqu铆 ir谩n todos los objetos dto para la petici贸n
response / # los dto de la response
domain/
repository/ # interfaz del repository
service/
Exception.java
Foo.java
infrastructure/
configuration/ # La configuraci贸n de las distintas bases de datos (MongoDB, Cassandra鈥).
# Tambi茅n configuraci贸n de los Beans (Services en este caso).
repository/ # Implementaci贸n de la interfaz repository para los distintos repositorios, tambi茅n mappers, Modelo de datos, etc.
Application.java

Ni Nueva Ni Arquitectura Ni Hexagonal, aqui

Ser铆a genial un curso donde se ponga en practica 茅sta arquitectura

Esto lo comento por mera experiencia.
Esta arquitectura esta muy ligada con los ejemplos que vimos en la arquitectura de capas y MVC.
La principal diferencia que se tiene es que en le hexagonal requiere que el dominio declare los puertos (generalmente como interfaces lo cual abstrae por completo el problema de separar la implementaci贸n de la abtracci贸n).
Son muy parecidos ya que en ambos separas las responsabilidades y en ambos casos el dominio desconoce los detalles de:

  • Quien lo llama o usa
  • C贸mo se manejan los datos.
  • Como se ejecutan ciertos procesos (ej, env铆o de email o notificaciones)
  • Como se muestra la informaci贸n (Por ejemplo, los servicios devuelve Array<Obj> y quien llamo al servicio [controller por ejemplo] generan un JSON o un CSV).

Para mi es una de las arquitecturas m谩s limpias. El principal inconveniente es que genera muchos archivos y se vuelve complicado de manejar. Adem谩s de que es m谩s complicado de implementar en lenguajes que no tienen validaci贸n de tipo de datos.

Como nota final, eta arquitectura es muy buena cuando tiene servicios complejos. Si estas realizando un API CRUD muy sencilla quiz谩 sea un overkill manejar esta arquitectura

En este v铆deo pueden verlo con un ejemplo en java muy al estilo hola mundo: https://www.youtube.com/watch?v=VLhdDYaW-uI&ab_channel=ManuelZapata

Arquitectura Hexagonal y DDD
Al ser una arquitectura que fomenta que nuestro dominio sea el n煤cleo de todas las capas (o regiones), y que no se acople a nada externo, encaja muy bien con la idea de DDD.