Introducción Los desarrolladores frontend a menudo se enfrentan a un problema relacionado con la arquitectura de la aplicación. Requiere el uso de una arquitectura que pueda escalarse fácilmente y proporcionar un acoplamiento flexible y una alta cohesión entre los módulos de la aplicación. Este artículo analiza la arquitectura Feature-Sliced Design, ya que, en mi opinión, es la mejor entre las opciones disponibles. También explora la idea de FSD y los problemas que resuelve esta metodología arquitectónica. Compararemos FSD con arquitecturas clásicas y modulares y examinaremos sus ventajas y desventajas. En primer lugar, distingamos tres conceptos: capa, corte y segmento. Capas Las capas son directorios de nivel superior y el primer nivel de descomposición de la aplicación. Están limitadas en número -un máximo de 7 capas- y estandarizadas, aunque algunas de ellas son opcionales. Actualmente se distinguen las siguientes capas: Cada capa tiene su propia zona de responsabilidad y está orientada al negocio. Consideremos cada capa por separado. aplicación: Aquí es donde se inicializa la lógica de la aplicación. Aquí se definen proveedores, enrutadores, estilos globales, declaraciones de tipos globales, etc. Sirve como punto de entrada para la aplicación. Procesos: esta capa maneja procesos que abarcan varias páginas, como el registro de varios pasos. Esta capa se considera obsoleta, pero todavía se puede encontrar ocasionalmente. Es una capa opcional. páginas: esta capa incluye las páginas de la aplicación. widgets: estos son componentes de interfaz de usuario independientes que se utilizan en las páginas. características: esta capa se ocupa de escenarios de usuario y funcionalidades que conllevan valor comercial. Por ejemplo, me gusta, escribir reseñas, calificar productos, etc. Es una capa opcional. entidades: esta capa representa entidades comerciales. Estas entidades pueden incluir usuarios, reseñas, comentarios, etc. Es una capa opcional. compartido: esta capa contiene componentes y utilidades reutilizables que no están vinculados a una lógica empresarial específica. Incluye un kit de interfaz de usuario, configuración de Axios, configuración de aplicaciones, ayudantes que no están vinculados a la lógica empresarial, etc. Estas capas ayudan a organizar el código base y promover una arquitectura modular, mantenible y escalable. Una de las características clave del Feature-Sliced Design es su estructura jerárquica. En esta estructura, las entidades no pueden usar la funcionalidad de las funciones porque las funciones están más arriba en la jerarquía. De manera similar, las funciones no pueden usar componentes de widgets o procesos, ya que las capas superiores solo pueden utilizar las capas inferiores. Esto se hace para mantener un flujo lineal que se dirige solo en una dirección. Cuanto más baja esté una capa en la jerarquía, más riesgoso será realizar cambios en ella, ya que es probable que se utilice en más lugares del código. Por ejemplo, el kit de interfaz de usuario en la capa compartida se utiliza en las funciones, los widgets e incluso en las capas de página. Rebanadas En cada una de las capas hay subdirectorios (slices), el segundo nivel de descomposición de la aplicación. En los sectores, la conexión no es con cosas abstractas sino con entidades comerciales específicas. El objetivo principal de los sectores es agrupar el código por su valor. Los nombres de los sectores no están estandarizados, ya que están determinados directamente por el área comercial del proyecto. Por ejemplo, en una galería de fotos, puede haber secciones como foto, álbum y galería. Una red social requeriría segmentos como publicaciones, usuarios y fuentes de noticias. Los fragmentos estrechamente relacionados se pueden agrupar estructuralmente en un directorio, pero deben cumplir con las mismas reglas de aislamiento que otros fragmentos; no debe haber acceso compartido al código en este directorio. Segmentos Cada rebanada consta de segmentos. Los segmentos ayudan a dividir el código dentro de un segmento según su propósito. Dependiendo de los acuerdos del equipo, los segmentos pueden cambiar en composición y nombre. Los siguientes segmentos se utilizan más comúnmente: api: solicitudes necesarias del servidor. UI: componentes de UI del segmento. modelo - Lógica empresarial, es decir, interacción con el Estado. Por ejemplo, acciones y selectores. lib: funcionalidad auxiliar utilizada dentro del segmento. config: configuración necesaria del segmento, pero el segmento de configuración rara vez se encuentra. consts - constantes necesarias. API pública Cada porción y segmento tiene una API pública. La API pública está representada por un archivo index.js o index.ts, que permite extraer solo la funcionalidad necesaria del segmento o segmento hacia el exterior y aislar la funcionalidad innecesaria. El archivo de índice sirve como punto de entrada. Reglas para la API pública: Los sectores y segmentos de la aplicación utilizan solo la funcionalidad y los componentes del sector que se definen en el archivo de índice de la API pública. La parte interna del segmento o segmento que no está definida en la API pública se considera aislada y solo se puede acceder a ella dentro del segmento o segmento en sí. La API pública simplifica el trabajo con la importación y la exportación, por lo que al realizar cambios en la aplicación, no es necesario cambiar las importaciones en todas partes del código. Más profundamente en la arquitectura Abstracción y lógica empresarial Cuanto más alta es la capa, más vinculada está al nodo empresarial específico y más lógica empresarial contiene. Cuanto más baja es la capa, más abstracciones, reutilización y falta de autonomía hay en la capa. ¿Cómo resuelve FSD el problema? Una de las tareas del diseño en rodajas es lograr un acoplamiento flexible y una alta cohesión. Es importante comprender cómo FSD logra este resultado. En POO, estos problemas se han resuelto durante mucho tiempo mediante conceptos como , , y . Estos conceptos aseguran el aislamiento, la reutilización y la versatilidad del código, donde se obtienen diferentes resultados dependiendo de cómo se utiliza un componente o funcionalidad. polimorfismo encapsulación herencia abstracción El diseño por secciones ayuda a aplicar estos principios en la interfaz. y se logran a través de capas. Dado que las capas inferiores son abstractas, se pueden reutilizar en capas superiores y, según las condiciones, un componente o funcionalidad puede funcionar de manera diferente según los parámetros o accesorios especificados. La abstracción el polimorfismo se logra a través de la API pública, que aísla lo que no se necesita del exterior en porciones y segmentos. El acceso a los segmentos internos de un segmento está restringido y la API pública es la única forma de acceder a la funcionalidad y los componentes de un segmento o segmento. La encapsulación también se logra a través de capas, ya que las capas superiores pueden reutilizar las capas inferiores. La herencia Comparación con la arquitectura clásica Creo que te has topado muchas veces con la arquitectura clásica. La mayoría de autores lo utilizan en artículos educativos y vídeos de YouTube debido a su sencillez. No existe un estándar específico para la arquitectura clásica. Sin embargo, a menudo puedes ver el siguiente formato: La arquitectura clásica tiene notables inconvenientes. El mayor es que el proyecto se vuelve difícil de mantener debido a las conexiones implícitas entre los componentes y el desorden de módulos. Los inconvenientes de la arquitectura clásica se hacen más evidentes con el tiempo. Cuanto más evoluciona el proyecto, más se convierte la arquitectura de la aplicación en un lío difícil de desentrañar. La arquitectura clásica es adecuada para proyectos pequeños sin mantenimiento continuo ni proyectos favoritos. Feature-Sliced Design, gracias a sus conceptos y estándares, previene los problemas de la arquitectura clásica. Sin embargo, el nivel de comprensión y habilidades de los desarrolladores que trabajan con FSD debería ser mayor que cuando trabajan con arquitectura clásica. Por lo general, los desarrolladores con menos de 2 años de experiencia no han oído hablar de FSD. Sin embargo, cuando se trabaja con Feature-Sliced Design, los problemas deben abordarse "ahora" y no "más adelante". Los problemas en el código y las desviaciones de los conceptos se hacen evidentes de inmediato. Comparación con la arquitectura modular simple La arquitectura modular simple tiene varios inconvenientes: A veces no está claro dónde colocar la funcionalidad en módulos o componentes. Dificultades para utilizar módulos dentro de otro módulo. Problemas con el almacenamiento de entidades comerciales. Dependencias implícitas en funciones globales, lo que lleva a una estructura enredada. Parece que en cualquier proyecto complejo o moderadamente complejo, se debe preferir el diseño por secciones a la arquitectura modular simple. FSD resuelve muchos problemas arquitectónicos fundamentales y tiene pocos inconvenientes. En términos de simplicidad y velocidad de desarrollo, una arquitectura modular simple puede tener una ventaja sobre FSD. Si se necesita un MVP o se está desarrollando un proyecto de corta duración, una arquitectura modular simple puede ser más adecuada que FSD. Pero en cualquier otro caso, parece preferible un diseño dividido en funciones. El potencial del diseño por funciones FSD es una metodología arquitectónica joven. Sin embargo, ya está siendo utilizado por muchas empresas bancarias, fintech, B2B, de comercio electrónico y otras. Aquí hay un enlace al problema de GitHub con una lista de empresas: . Problema de GitHub El repositorio de GitHub con la documentación oficial de FSD tenía más de 1,1 mil estrellas al momento de publicar este artículo. La documentación se está ampliando activamente y el equipo de desarrollo de FSD y la comunidad en Telegram y Discord están disponibles las 24 horas del día, los 7 días de la semana para ayudar a las personas con preguntas relacionadas con la arquitectura. El potencial de esta arquitectura es muy apreciado y su uso está ampliamente extendido entre las grandes empresas de todo el mundo. Con una adopción adecuada, FSD tiene el potencial de convertirse en la solución arquitectónica dominante en el campo del desarrollo frontend. Ventajas y desventajas de la arquitectura Ventajas Los componentes de la arquitectura se pueden reemplazar, agregar o eliminar fácilmente Estandarización de la arquitectura. Escalabilidad La metodología es independiente de la pila de desarrollo. Conexiones controladas y explícitas entre módulos sin efectos secundarios inesperados. Metodología arquitectónica orientada al negocio. Desventajas Una barrera de entrada más alta en comparación con muchas otras soluciones arquitectónicas. Requiere conciencia, cultura de equipo y adherencia a conceptos. Los desafíos y problemas deben abordarse de inmediato y no más tarde. Los problemas de código y las desviaciones de los conceptos son inmediatamente visibles. Sin embargo, esto también puede verse como una ventaja. Conclusión El diseño por secciones es un descubrimiento interesante y valioso que los desarrolladores frontend deberían conocer y poder utilizar. FSD puede proporcionar a los equipos una arquitectura y una cultura de desarrollo flexibles, estandarizadas y escalables. Sin embargo, utilizar los aspectos positivos de la metodología requiere conocimiento, conciencia y disciplina dentro del equipo. FSD se destaca entre otras arquitecturas debido a su clara orientación comercial, definición de entidades, composición funcional y composición de componentes de la aplicación. También puede explorar de forma independiente ejemplos de uso de FSD en proyectos y la documentación oficial de Feature-Sliced Design: Documentación oficial Ejemplo. Cliente GitHub Ejemplo. Tienda de zapatillas y calzado Nike Ejemplo. Sudokus Esta publicación puede ser larga, pero espero que hayas aprendido algo nuevo. Aprecio que hayas terminado de leer esta publicación. Si tienes alguna idea o pregunta, ¡no dudes en dejar un comentario! También publicado aquí

This story contains new, firsthand information uncovered by the writer.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

Read My Stories

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

La mejor arquitectura frontend compleja: lo que necesita saber sobre el diseño por funciones

Demasiado Largo; Para Leer

Yan Levin

STORY’S CREDIBILITY

Original Reporting

DYOR

Review

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

La mejor arquitectura frontend compleja: lo que necesita saber sobre el diseño por funciones

Demasiado Largo; Para Leer

Yan Levin

STORY’S CREDIBILITY

Original Reporting

DYOR

Review

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS