> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md). # W27-Diseño guiado por el dominio y patrones de interacción entre frontend y backend #### **Algunas reflexiones sobre el diseño guiado por el dominio** **Cómo mantener estable el núcleo de nuestros proyectos en medio de cambios rápidos, sin que la complejidad se descontrole en las siguientes iteraciones hasta obligarnos a reconstruirlos.** Ya nos enfrentamos a la pérdida de conocimiento del negocio al transmitirlo dentro del equipo. A medida que el equipo crezca y cambien sus integrantes, el problema solo se agravará. **¿Cuál es ese núcleo? La comprensión y abstracción del negocio. Trasladado al diseño de software, creo que se trata del diseño basado en el dominio.** En comparación con el frontend, el backend suele tener un diseño más detallado y de mayor alcance. Un proyecto debe basarse en una comprensión profunda del negocio. Cuanto más profunda sea esa comprensión y más completa la abstracción, mejores serán su mantenibilidad y extensibilidad. En cierto sentido, sin diseño quizá ni siquiera se pueda empezar a desarrollar el backend. El frontend es distinto. Nuestras propuestas técnicas se concentran más en aspectos puramente técnicos y en la implementación de los procesos de negocio. Todavía no descomponemos el negocio con suficiente profundidad. Sinceramente, **el diseño de nuestras soluciones sigue estando, en lo esencial, orientado a implementar páginas**. Rara vez vemos una abstracción del negocio a partir de la cual se diseñen los componentes y las capas estructurales del software. En un buen proyecto de backend, la estructura de las tablas y la capa de servicios son relativamente estables gracias a una comprensión y abstracción profundas del dominio del negocio. El producto para comerciantes está ahora en una etapa de evolución rápida del negocio, por lo que la interfaz y las interacciones también cambiarán rápidamente. ¿Cómo responder al mayor número posible de cambios desde una base estable? ¿Cómo apoyar el crecimiento del negocio con un costo global menor? Quiero encontrar la respuesta en el diseño guiado por el dominio. Tomemos como ejemplo el módulo de pago. En esta reconstrucción de la versión i, organizamos toda la aplicación mediante componentes contenedores y componentes de presentación. Los contenedores gestionan el estado y la lógica de negocio; los de presentación son componentes puros que solo relacionan los datos con la vista. La lógica de negocio del frontend del módulo de pago no es especialmente compleja, pero el componente contenedor ya supera las 600 líneas. Por ahora sigue bastante claro, aunque pronto añadiremos pagos con préstamos, con fondos de gestión patrimonial y funciones de marketing. El contenedor no dejará de crecer. ¿Qué hacer? Hay que dividirlo. ¿Cómo? Por dominios. El núcleo del frontend de pago consiste en gestionar métodos de pago. Deberíamos abstraer en dominios los métodos con distintas características de negocio. Cada método de pago tiene un proveedor de activos diferente, por lo que puede entenderse como un dominio. Los distintos dominios tienen sus propios atributos y comportamientos. Por ejemplo, el pago rápido tiene como atributo una lista de tarjetas y como comportamiento seleccionar una tarjeta e introducir la contraseña. El pago con préstamo tiene atributos como el número de cuotas y el importe, y comportamientos como solicitar el préstamo mediante reconocimiento facial u obtener el contrato del préstamo. Estas son las bases de la lógica de negocio y son relativamente estables. Cambie como cambie la interfaz en el futuro, el núcleo del proyecto, la capa de dominio, no cambiará. Incluso al pasar la tecnología de frontend de Vue a React, ese núcleo puede migrarse de forma estable. Yo tampoco había trabajado suficientemente bien esta parte del diseño. Mis ideas sobre el diseño guiado por el dominio todavía necesitan más intercambio y contraste para seguir evolucionando. #### **Algunas experiencias sobre los patrones de intercambio de datos entre frontend y backend** Frente al negocio de la billetera, el de pagos presenta diferencias claras en el diseño de la interacción entre las interfaces de frontend y backend. En servicios de pago como el módulo de pago, la vinculación de tarjetas o el pago de cuentas, las API ofrecidas al frontend están diseñadas, básicamente, en función de las páginas. La relación entre interfaces sigue por completo la secuencia temporal de la interacción entre persona y computadora. Una interfaz devuelve la URL de la siguiente, sus parámetros de petición y todo lo que necesita la página actual. Solo falta que devuelva la propia página ya renderizada. La ventaja es que la responsabilidad del frontend se concentra casi exclusivamente en la interacción con el usuario y parece muy acotada. El backend dispone de un control relativamente flexible de la secuencia de interfaces: puede decidir libremente cuáles siguen, llamar a distintos servicios posteriores y devolver los datos, sin tener que negociar el proceso con el frontend. Los inconvenientes también son claros. Este modelo acopla estrechamente las API con las vistas o, dicho de otra manera, con el flujo de interacción con el usuario. Su extensibilidad es, en realidad, muy frágil. Este modo de colaboración funciona porque las vistas del frontend y los procesos de negocio son suficientemente estables. De hecho, los pagos cumplen bastante bien esa condición. Aunque el modelo sea poco generalizable, si se eligió desde el diseño de la arquitectura de pagos, seguramente hubo consideraciones de fondo. Por ahora, en este contexto no puedo decir que sea absolutamente bueno o malo. Necesito seguir comprendiéndolo a través del trabajo con el negocio. **En el proyecto de pago rápido, la interfaz A devuelve la interfaz a la que se debe enviar la siguiente petición y determina las interfaces posteriores. El backend necesita conocer la versión del frontend, ya sea mediante un número de versión o mediante un despliegue gradual de toda la cadena que tome el ID del cliente como referencia.**