Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas

Modele el dominio empresarial

Trabaje desde el ámbito empresarial hasta el diseño del software para asegurarse de que el software que está diseñando se ajusta a las necesidades empresariales.

Utilice metodologías de diseño basado en el dominio (DDD), como la tormenta de eventos, para modelar el ámbito empresarial. Event Storming tiene un formato de taller flexible. Durante el taller, los expertos en dominios y software exploran la complejidad del ámbito empresarial de forma colaborativa. Los expertos en software utilizan los resultados del taller para iniciar el proceso de diseño y desarrollo de los componentes de software.

Escribe y ejecuta pruebas desde el principio

Utilice el desarrollo basado en pruebas (TDD) para verificar la exactitud del software que está desarrollando. El TDD funciona mejor a nivel de pruebas unitarias. El desarrollador diseña un componente de software escribiendo primero una prueba, que invoca ese componente. Ese componente no está implementado al principio, por lo que la prueba falla. Como siguiente paso, el desarrollador implementa la funcionalidad del componente, utilizando dispositivos de prueba con objetos simulados para simular el comportamiento de las dependencias externas o puertos. Cuando la prueba sea exitosa, el desarrollador puede continuar implementando adaptadores reales. Este enfoque mejora la calidad del software y da como resultado un código más legible, ya que los desarrolladores entienden cómo utilizarían los usuarios los componentes. La arquitectura hexagonal es compatible con la metodología TDD al separar el núcleo de la aplicación. Los desarrolladores escriben pruebas unitarias que se centran en el comportamiento del núcleo del dominio. No tienen que escribir adaptadores complejos para ejecutar sus pruebas; en su lugar, pueden usar dispositivos y objetos simulados simples.

Utilice el desarrollo impulsado por el comportamiento (BDD) para garantizar la end-to-end aceptación a nivel de función. En BDD, los desarrolladores definen escenarios para las características y los verifican con las partes interesadas de la empresa. Para ello, las pruebas de BDD utilizan la mayor cantidad de lenguaje natural posible. La arquitectura hexagonal apoya la metodología BDD con su concepto de adaptadores primarios y secundarios. Los desarrolladores pueden crear adaptadores principales y secundarios que se ejecuten localmente sin necesidad de recurrir a servicios externos. Configuran el conjunto de pruebas de BDD para usar el adaptador principal local para ejecutar la aplicación.

Ejecute automáticamente cada prueba en el proceso de integración continua para evaluar constantemente la calidad del sistema.

Defina el comportamiento del dominio

Descomponga el dominio en entidades, objetos de valor y agregados (lea acerca de la implementación del diseño basado en dominios) y defina su comportamiento. Implemente el comportamiento del dominio para que las pruebas que se escribieron al principio del proyecto tengan éxito. Defina comandos que invoquen el comportamiento de los objetos del dominio. Defina los eventos que emiten los objetos de dominio después de completar un comportamiento.

Defina las interfaces que los adaptadores pueden usar para interactuar con el dominio.

Automatice las pruebas y la implementación

Tras una prueba de concepto inicial, le recomendamos que invierta tiempo en implementar DevOps las prácticas. Por ejemplo, las canalizaciones de integración y entrega continuas (CI/CD) y los entornos de prueba dinámicos ayudan a mantener la calidad del código y a evitar errores durante la implementación.

Amplíe su producto mediante microservicios y CQRS

Si su producto tiene éxito, amplíe su producto descomponiendo su proyecto de software en microservicios. Utilice la portabilidad que ofrece la arquitectura hexagonal para mejorar el rendimiento. Divida los servicios de consultas y los controladores de comandos en síncronos y asíncronos independientes. APIs Considere la posibilidad de adoptar el patrón de segregación de responsabilidades por consultas de comandos (CQRS) y una arquitectura basada en eventos.

Si recibe muchas solicitudes de funciones nuevas, considere la posibilidad de ampliar su organización en función de los patrones DDD. Estructura tus equipos de forma que posean una o más funciones como contextos acotados, como se ha explicado anteriormente en esta sección. Escalamiento organizacional Luego, estos equipos pueden implementar la lógica empresarial mediante una arquitectura hexagonal.

Diseñe una estructura de proyecto que se adapte a los conceptos de arquitectura hexagonal

La infraestructura como código (IaC) es una práctica ampliamente adoptada en el desarrollo de la nube. Le permite definir y mantener sus recursos de infraestructura (como redes, balanceadores de carga, máquinas virtuales y puertas de enlace) como código fuente. De esta forma, puede realizar un seguimiento de todos los cambios en su arquitectura mediante un sistema de control de versiones. Además, puede crear y mover la infraestructura fácilmente con fines de prueba. Le recomendamos que mantenga el código de la aplicación y el código de la infraestructura en el mismo repositorio cuando desarrolle sus aplicaciones en la nube. Este enfoque facilita el mantenimiento de la infraestructura de su aplicación.

Se recomienda dividir la aplicación en tres carpetas o proyectos que se adapten a los conceptos de la arquitectura hexagonal: entrypoints (adaptadores principales), domain (dominio e interfaces) y adapters (adaptadores secundarios).

La siguiente estructura de proyecto proporciona un ejemplo de este enfoque a la hora de diseñar una API en AWS. El proyecto mantiene el código de aplicación (app) y el código de infraestructura (infra) en el mismo repositorio, tal y como se recomendó anteriormente.

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code 

Como se mencionó anteriormente, el dominio es el núcleo de la aplicación y no depende de ningún otro módulo. Se recomienda estructurar la domain carpeta para incluir las siguientes subcarpetas:

Los adaptadores principales son los puntos de entrada a la aplicación, tal como se representa en la entrypoints carpeta. En este ejemplo, se utiliza la api carpeta como adaptador principal. Esta carpeta contiene una APImodel, que define la interfaz que necesita el adaptador principal para comunicarse con los clientes. La tests carpeta contiene end-to-end las pruebas de la API. Se trata de pruebas superficiales que validan que los componentes de la aplicación estén integrados y funcionen en armonía.

Los adaptadores secundarios, representados por la adapters carpeta, implementan las integraciones externas que requieren los puertos del dominio. Un repositorio de base de datos es un excelente ejemplo de adaptador secundario. Cuando el sistema de base de datos cambia, puede escribir un adaptador nuevo mediante la implementación definida por el dominio. No es necesario cambiar el dominio ni la lógica empresarial. La tests subcarpeta contiene pruebas de integración externas para cada adaptador.