Construir arquitecturas hexagonales en AWS

Furkan Oruc, Dominik Goby, Darius Kunce y Michal Ploski, Amazon Web Services ()AWS

junio de 2022 (historial de documentos)

Esta guía describe un modelo mental y una colección de patrones para desarrollar arquitecturas de software. Estas arquitecturas son fáciles de mantener, ampliar y escalar en toda la organización a medida que crece la adopción de productos. Los hiperescaladores en la nube, como Amazon Web Services (AWS), proporcionan componentes básicos para que las pequeñas y grandes empresas innoven y creen nuevos productos de software. El rápido ritmo de presentación de estos nuevos servicios y funciones hace que las partes interesadas de la empresa esperen que sus equipos de desarrollo puedan crear prototipos de nuevos productos mínimamente viables (MVPs) con mayor rapidez, de modo que las nuevas ideas puedan probarse y verificarse lo antes posible. A menudo, MVPs se adoptan y pasan a formar parte del ecosistema de software empresarial. En el proceso de crearlos MVPs, los equipos a veces abandonan las reglas y las mejores prácticas de desarrollo de software, como los principios de SOLID y las pruebas unitarias. Asumen que este enfoque acelerará el desarrollo y reducirá el tiempo de comercialización. Sin embargo, si no logran crear un modelo fundamental y un marco para la arquitectura del software en todos los niveles, será difícil o incluso imposible desarrollar nuevas funciones para el producto. La falta de certeza y los requisitos cambiantes también pueden ralentizar al equipo durante el proceso de desarrollo.

Esta guía describe una arquitectura de software propuesta, desde una arquitectura hexagonal de bajo nivel hasta una descomposición arquitectónica y organizacional de alto nivel, que utiliza el diseño impulsado por el dominio (DDD) para abordar estos desafíos. El DDD ayuda a gestionar la complejidad empresarial y a ampliar el equipo de ingeniería a medida que se desarrollan nuevas funciones. Permite alinear a las partes interesadas empresariales y técnicas con los problemas empresariales, denominados dominios, mediante el uso de un lenguaje ubicuo. La arquitectura hexagonal posibilita técnicamente este enfoque en un dominio muy específico, denominado contexto limitado. Un contexto acotado es una subárea del problema empresarial muy cohesiva y débilmente acoplada. Le recomendamos que adopte una arquitectura hexagonal para todos sus proyectos de software empresarial, independientemente de su complejidad.

La arquitectura hexagonal alienta al equipo de ingeniería a resolver primero el problema empresarial, mientras que la arquitectura clásica en capas deja de centrarse en el dominio de la ingeniería para centrarse primero en resolver los problemas técnicos. Además, si el software sigue una arquitectura hexagonal, es más fácil adoptar un enfoque de desarrollo basado en pruebas, lo que reduce el ciclo de retroalimentación que los desarrolladores necesitan para probar los requisitos empresariales. Por último, el uso de comandos y controladores de comandos es una forma de aplicar los principios de responsabilidad única y de apertura y cierre de SOLID. La adhesión a estos principios crea una base de código que los desarrolladores y arquitectos que trabajan en el proyecto pueden entender y entender fácilmente, y reduce el riesgo de introducir cambios importantes en la funcionalidad existente.

Esta guía está dirigida a arquitectos y desarrolladores de software que estén interesados en comprender las ventajas de adoptar la arquitectura hexagonal y la DDD para sus proyectos de desarrollo de software. Incluye un ejemplo del diseño de una infraestructura para su aplicación AWS que sea compatible con una arquitectura hexagonal. Para ver un ejemplo de implementación, consulte Estructurar un proyecto de Python en una arquitectura hexagonal utilizando el AWS Lambda sitio web AWS Prescriptive Guidance.