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 dominio empresarial hasta el diseño del software para asegurarse de que el software que está escribiendo se ajusta a las necesidades empresariales.

Utilice metodologías de diseño basado en dominios (DDD), como la tormenta de eventos, para modelar el dominio empresarial. Event Storming tiene un formato de taller flexible. Durante el taller, los expertos en dominios y software exploran la complejidad del dominio 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 prueba unitaria. El desarrollador diseña un componente de software escribiendo primero una prueba, que invoca ese componente. Ese componente no tiene ninguna implementación 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 o puertos externos. Cuando la prueba tenga éxito, 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 los usuarios usarían los componentes. La arquitectura hexagonal apoya 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 objetos y accesorios simulados simples.

Utilice el desarrollo basado en el comportamiento (BDD) para garantizar end-to-end la aceptación a nivel de funcionalidad. En BDD, los desarrolladores definen escenarios para las funciones y los verifican con las partes interesadas de la empresa. Las pruebas de BDD utilizan tanto lenguaje natural como sea posible para lograrlo. 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 pueden ejecutarse localmente sin necesidad de llamar a servicios externos. Configuran el conjunto de pruebas 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.

Definir el comportamiento del dominio

Descomponga el dominio en entidades, objetos de valor y agregados (lea sobre cómo implementar un 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 de 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 prueba e implementación

Tras una prueba de concepto inicial, le recomendamos que dedique tiempo a implementar DevOps prácticas. Por ejemplo, las canalizaciones de integración continua y entrega continua (CI/CD) y los entornos de pruebas 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 proporciona la arquitectura hexagonal para mejorar el rendimiento. Divida los servicios de consulta y los controladores de comandos en API sincrónicas y asincrónicas independientes. Considere adoptar el patrón de segregación de responsabilidades de consultas de comandos (CQRS) y la 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 de DDD. Estructure sus equipos de tal manera que sean propietarios de una o más funciones como contextos acotados, como se ha explicado anteriormente en laOrganizational sección. Luego, estos equipos pueden implementar la lógica empresarial mediante el uso de 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 pasarelas) 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, es posible crear y mover fácilmente la infraestructura para prueba. Le recomendamos que mantenga el código de la aplicación y el código de infraestructura en el mismo repositorio cuando desarrolle sus aplicaciones en la nube. Este enfoque permite mantener fácilmente la infraestructura de su aplicación.

Le recomendamos que divida la aplicación en tres carpetas o proyectos que correspondan a los conceptos de la arquitectura hexagonal:entrypoints (adaptadores principales),domain (dominio e interfaces) yadapters (adaptadores secundarios).

La siguiente estructura de proyecto proporciona un ejemplo de este enfoque al diseñar una API enAWS. El proyecto mantiene el código de la aplicación (app) y el código de infraestructura (infra) en el mismo repositorio, tal 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 ladomain carpeta para incluir las siguientes subcarpetas:

Los adaptadores principales son los puntos de entrada a la aplicación, tal como los representa laentrypoints carpeta. En este ejemplo se utiliza laapi carpeta como adaptador principal. Esta carpeta contiene una APImodel, que define la interfaz que el adaptador principal requiere para comunicarse con los clientes. Latests 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 funcionan en armonía.

Los adaptadores secundarios, tal como los representa laadapters carpeta, implementan las integraciones externas que requieren los puertos de dominio. Un repositorio de bases de datos es un excelente ejemplo de adaptador secundario. Cuando cambie el sistema de base de datos, puede escribir un nuevo adaptador mediante la implementación definida por el dominio. No es necesario cambiar el dominio o la lógica empresarial. Latests subcarpeta contiene pruebas de integración externas para cada adaptador.