Conceptos fundamentales

La arquitectura microfrontend se inspira en gran medida en tres conceptos arquitectónicos anteriores:

• El diseño basado en dominios es el modelo mental para estructurar aplicaciones complejas en dominios coherentes.

• Los sistemas distribuidos son un enfoque para crear aplicaciones como subsistemas débilmente acoplados que se desarrollan de forma independiente y se ejecutan en su propia infraestructura dedicada.

• La computación en la nube es un enfoque para ejecutar la infraestructura de TI como servicios con un pay-as-you-go modelo.

Diseño basado en el dominio

El diseño impulsado por dominios (DDD) es un paradigma desarrollado por Eric Evans. En su libro de 2003 Domain-Driven Design: Tackling Complexity in the Heart of Software, Evans postula que el desarrollo de software debe estar impulsado por preocupaciones empresariales y no por cuestiones técnicas. Evans propone que los proyectos de TI desarrollen primero un lenguaje ubicuo que ayude a los expertos técnicos y del campo a encontrar un entendimiento común. Basándose en ese lenguaje, pueden formular un modelo de la realidad empresarial que se comprenda mutuamente.

Por obvio que sea ese enfoque, muchos proyectos de software sufren una desconexión entre la empresa y la TI. Esas desconexiones suelen provocar importantes malentendidos, que se traducen en sobrecostos presupuestarios, en una disminución de la calidad o en el fracaso de los proyectos.

Evans introduce muchos otros términos importantes, uno de los cuales es el contexto limitado. Un contexto limitado es un segmento autónomo de una gran aplicación de TI que contiene la solución o implementación para exactamente una empresa empresarial. Una aplicación de gran tamaño constará de varios contextos acotados que se acoplan de forma flexible mediante patrones de integración. Esos contextos acotados pueden incluso tener sus propios dialectos del idioma ubicuo. Por ejemplo, un usuario en el contexto de pagos de una aplicación podría tener aspectos diferentes a los de un usuario en el contexto de la entrega, ya que la noción de envío sería irrelevante durante el pago.

Evans no define qué tan pequeño o grande debe ser un contexto acotado. El tamaño lo determina el proyecto de software y puede evolucionar con el tiempo. Los buenos indicadores de los límites de un contexto son el grado de cohesión entre las entidades (objetos de dominio) y la lógica empresarial.

En el contexto de las microinterfaces, el diseño basado en el dominio puede ilustrarse con el ejemplo de una página web compleja, como una página de reserva de vuelos.

En esta página, los componentes principales son un formulario de búsqueda, un panel de filtros y la lista de resultados. Para identificar los límites, debe identificar los contextos funcionales independientes. Además, tenga en cuenta los aspectos no funcionales, como la reutilización, el rendimiento y la seguridad. El indicador más importante de que «las cosas van juntas» son sus patrones de comunicación. Si algunos elementos de una arquitectura deben comunicarse con frecuencia e intercambiar información compleja, es probable que compartan el mismo contexto limitado.

Los elementos individuales de la interfaz de usuario, como los botones, no son contextos acotados, ya que no son independientes desde el punto de vista funcional. Además, la página completa no es adecuada para un contexto limitado, ya que se puede dividir en contextos independientes más pequeños. Un enfoque razonable consiste en tratar el formulario de búsqueda como un contexto acotado y tratar la lista de resultados como el segundo contexto acotado. Cada uno de estos dos contextos acotados ahora se puede implementar como una microinterfaz independiente.

Sistemas distribuidos

Para facilitar el mantenimiento y respaldar la capacidad de evolución, la mayoría de las soluciones de TI no triviales son modulares. En este caso, modular significa que los sistemas de TI constan de componentes básicos identificables que se disocian mediante interfaces para lograr separar las preocupaciones.

Además de ser modulares, los sistemas distribuidos deben ser sistemas independientes por derecho propio. En un sistema meramente modular, cada módulo está encapsulado idealmente y expone sus funciones a través de interfaces, pero no se puede implementar de forma independiente ni siquiera funcionar por sí solo. Además, los módulos suelen seguir el mismo ciclo de vida que otros módulos que forman parte del mismo sistema. Por otro lado, cada uno de los componentes básicos de un sistema distribuido tiene sus propios ciclos de vida. Al aplicar el paradigma del diseño basado en el dominio, cada componente básico se dirige a un dominio o subdominio empresarial y vive en su propio contexto limitado.

Cuando los sistemas distribuidos interactúan durante el tiempo de construcción, un enfoque común es desarrollar mecanismos para identificar los problemas rápidamente. Por ejemplo, puede adoptar lenguajes mecanografiados e invertir mucho en pruebas unitarias. Varios equipos pueden colaborar en el desarrollo y el mantenimiento de los módulos, que suelen distribuirse como bibliotecas para que los sistemas los consuman con herramientas como npm, Apache Maven y pip NuGet.

Durante el tiempo de ejecución, los sistemas distribuidos que interactúan suelen ser propiedad de equipos individuales. El consumo de dependencias provoca complejidad operativa debido a la gestión de errores, el equilibrio del rendimiento y la seguridad. Las inversiones en las pruebas de integración y la observabilidad son fundamentales para reducir los riesgos.

Los ejemplos más populares de sistemas distribuidos en la actualidad son los microservicios. En las arquitecturas de microservicios, los servicios de backend dependen del dominio (y no están motivados por cuestiones técnicas como la interfaz de usuario o la autenticación) y son propiedad de equipos autónomos. Las microinterfaces comparten los mismos principios, lo que amplía el alcance de la solución a la interfaz.

Computación en la nube

La computación en la nube es una forma de adquirir infraestructura de TI como servicios con un pay-as-you-go modelo, en lugar de construir sus propios centros de datos y comprar hardware para operarlos in situ. La computación en nube ofrece varias ventajas:

• Su organización obtiene una agilidad empresarial significativa al poder experimentar con nuevas tecnologías sin tener que asumir grandes compromisos financieros a largo plazo por adelantado.

• Al utilizar un proveedor de servicios en la nube, por ejemplo AWS, su organización puede acceder a una amplia cartera de servicios que requieren poco mantenimiento y son altamente integrables (como pasarelas de API, bases de datos, organización de contenedores y capacidades de nube). El acceso a estos servicios permite a su personal centrarse en el trabajo que diferencia a su organización de la competencia.

• Cuando su organización esté lista para implementar una solución a nivel mundial, podrá implementarla en la infraestructura de la nube de todo el mundo.

La computación en la nube es compatible con las microinterfaces al proporcionar una infraestructura altamente gestionada. Esto facilita end-to-end la propiedad para los equipos multifuncionales. Si bien el equipo debe tener sólidos conocimientos sobre operaciones, las tareas manuales de aprovisionamiento de la infraestructura, actualizaciones del sistema operativo y redes serían una distracción.

Como las microinterfaces se encuentran en contextos limitados, los equipos pueden elegir el servicio más adecuado para ejecutarlas. Por ejemplo, los equipos pueden elegir entre funciones de nube y contenedores para el procesamiento, y pueden elegir entre diferentes tipos de bases de datos SQL y NoSQL o cachés en memoria. Los equipos pueden incluso crear sus microinterfaces a partir de un conjunto de herramientas altamente integrado, por ejemplo AWS Amplify, que incluye componentes básicos preconfigurados para una infraestructura sin servidor.