Módulos de Funcionalidad para Aplicaciones a Prueba de FuturoMódulos de Funcionalidad para Aplicaciones a Prueba de Futuro

Los módulos de funcionalidad son un concepto sencillo pero muy infrautilizado en el Desarrollo Frontend. Es tan razonable que te preguntarás cómo es posible que no lo hayas estado usando antes. No usar módulos de funcionalidad hace que tu proyecto sea más difícil de navegar, aumenta los conflictos de merge y reduce su escalabilidad. ¿Quieres encontrar una solución? ¡Vamos a ello!

#¿Cuál es el reto de agrupar código?

¿Alguna vez has tenido una carpeta services acechando en tu proyecto? ¿Y una components? ¿Quizás api?

Ese tipo de carpetas puede crecer sin control bastante rápido. No hay nada malo en ellas en sí; es una cuestión de elegir a qué nivel de anidamiento están. Cuando están suficientemente anidadas, no son tan peligrosas.

Veamos un ejemplo:

src/
├── components/
│   ├── button.tsx
│   ├── login-form.tsx
│   ├── signup-form.tsx
│   └── profile-card.tsx
│
├── services/
│   ├── auth.service.ts
│   ├── dashboard.service.ts
│   └── profile.service.ts
│
├── api/
│   ├── auth.api.ts
│   ├── dashboard.api.ts
│   └── profile.api.ts
│
├── hooks/
│   ├── useAuth.ts
│   ├── useDashboard.ts
│   └── useProfile.ts
│
├── pages/
│   ├── login.page.tsx
│   ├── dashboard.page.tsx
│   └── profile.page.tsx
│
├── utils/
│   └── format-date.ts
│
└── main.tsx

Todo aquí está agrupado por tipo, no por propósito.

Esto es lo que llamamos agrupar código por tipo.

Si este proyecto fuera a quedarse con este conjunto de archivos para siempre, podríamos decir que es bastante manejable. Sin embargo, sabemos que los proyectos de desarrollo de software no dejan de cambiar y crecer.

En un futuro no muy lejano podríamos encontrarnos con la siguiente carpeta:

src/
└──  services/
    ├── auth.service.ts
    ├── user.service.ts
    ├── profile.service.ts
    ├── dashboard.service.ts
    ├── notifications.service.ts
    ├── payments.service.ts
    ├── orders.service.ts
    ├── products.service.ts
    ├── cart.service.ts
    ├── reviews.service.ts
    ├── search.service.ts
    ├── analytics.service.ts
    ├── settings.service.ts
    ├── messages.service.ts
    ├── subscriptions.service.ts
    ├── billing.service.ts
    ├── shipping.service.ts
    ├── inventory.service.ts
    ├── wishlist.service.ts
    └── support.service.ts

Problemático, ¿verdad?

Demos un paso atrás, ¿qué nos está faltando?

#¿Cómo saber cómo agrupar el código?

En un proyecto dado tendemos a olvidar que estamos tratando con ciertos conceptos que no son puramente técnicos.

Imaginemos que estamos hablando de una aplicación que calcula viajes espaciales intergalácticos. Cuando un usuario describe las funcionalidades de dicha aplicación no menciona components, api ni services, menciona cosas como usuarios, viaje, nave-espacial o destino.

Esta aparentemente trivial agrupación de palabras es de suma importancia. Identificar conceptos y unificar el lenguaje que usamos para referirnos al mismo concepto es uno de nuestros mayores activos como desarrolladores.

El esfuerzo de crear un modelo de lenguaje propio al describir la aplicación se conoce habitualmente como Ubiquitous languageSe abre en una nueva pestaña (lenguaje ubicuo).

“

Usar el lenguaje con precisión es nuestro mayor activo como desarrolladores.

”

Este concepto apareció por primera vez en Domain Driven DesignSe abre en una nueva pestaña. Eric EvansSe abre en una nueva pestaña (su autor) describe lo importante que es que usuarios y desarrolladores hablen el mismo idioma. Conociendo la importancia de esto, ahora podemos encontrar una solución a nuestro problema.

#Agrupar código por funcionalidad

En las conversaciones con los usuarios irán apareciendo conceptos. Entonces, ¿y si usamos esos conceptos para agrupar nuestro código?

src/
└── features/
    ├── auth/
    ├── dashboard/
    └── profile/

Ahora cada funcionalidad es autocontenida.

Algo tan simple, pero muy efectivo. Ahora surge la pregunta: ¿qué pasa con el resto de archivos?

Pues como dijimos, no hay nada malo en tener una carpeta services, components o api, simplemente es una cuestión de anidamiento.

src/
└── features/
    ├── auth/
    │   ├── components/
    │   ├── services/
    │   └── api/
    │
    ├── dashboard/
    │   ├── components/
    │   ├── services/
    │   └── api/
    │
    └── profile/
        ├── components/
        ├── services/
        └── api/

  src/
  └── features/
      ├── auth/
      │   ├── domain/
      │   ├── application/
      │   ├── delivery/
      │   └── infrastructure/
      │
      ├── dashboard/
      │   ├── domain/
      │   ├── application/
      │   ├── delivery/
      │   └── infrastructure/
      │
      └── profile/
          ├── domain/
          ├── application/
          ├── delivery/
          └── infrastructure/

#Beneficios de agrupar código por funcionalidades

Este simple cambio tiene muchos beneficios. Por ejemplo, cuando necesitamos modificar una funcionalidad de nuestra aplicación ya no tenemos que saltar de la carpeta services a components para luego encontrar los componentes relacionados con, por ejemplo, el dashboard.

Ahora simplemente vamos a la carpeta dashboard y, encontramos todo lo que necesitamos ahí.

Otro beneficio es que, al estar las cosas agrupadas por lo que representan y no por lo que son, tendremos menos colisiones con otras compañeras, facilitando la paralelización del proyecto.

Y si un módulo crece demasiado, podemos extraerlo como una aplicación o servicio independiente cuando sea necesario.

Así que los beneficios son:

1. Colocalización: Todo lo relacionado vive junto

2. Menos conflictos: Los equipos no se solapan

3. Escalable: Fácil de extraer

#Conclusión

Agrupar por funcionalidad en lugar de por tipo es una forma sencilla de asegurarse de que tu Arquitectura Frontend sea escalable por defecto. Aporta muchos beneficios y es algo que no veo a menudo en las plantillas de proyectos habituales que encuentro online, por lo que es fácil pasarlo por alto.

“

La estructura sigue al lenguaje.

”

¡Y ahora, a votar!

He añadido un nuevo componente de encuesta para que puedas decirme sobre qué debería hablar en el próximo número de esta newsletter.

Es una encuesta de un solo clic. Fácil y muy útil para mí. Ya que no registro si los correos se abren o se leen (porque valoro tu privacidad), también usaré este componente para saber cuántas personas realmente leen la newsletter. ¡Muy ingenioso he de decir!

P.D: Antes de irte, me alegra muchísimo compartir que he sido seleccionado para hablar en Codemotion MadridSe abre en una nueva pestaña, Commit ConfSe abre en una nueva pestaña y React SummitSe abre en una nueva pestaña. ¡Así que si estás pensando en asistir a alguna de esas conferencias, nos vemos allí!

P.D 2: Ricardo Benítez de Programando en JavaSe abre en una nueva pestaña me hizo una entrevista. Puedes ver la entrevista en español aquíSe abre en una nueva pestaña.

P.D 3: Gracias por leer, aprecio de verdad tu tiempo y atención.