RFC-0004 11-09-2024 Manejo de carpetas en backend

[ManuelMendozaa]

La intención de este RFC es discutir las estructuras de carpetas que deberían seguir los proyectos. Lo que se busca solucionar en principio es tener una distribución de archivos mucho más auto-descriptiva y evitar la aglomeración del código en un mismo lugar.

[rsca7213]

Considero que los problemas actuales que poseemos en la estructura de carpetas del Backend se podrían resumir en lo siguiente:

• Integrations: Se necesita de una carpeta que sirva específicamente para realizar integraciones con otros sistemas distintos al Backend que nos encontramos desarrollando. Por ejemplo: Twilio, Stripe, Postmark.
• Services: Los servicios pueden llegar a ser extremadamente grandes (> 1000 líneas), Para esto creo que seria de gran utilidad poder separar el servicio de un componente en multiples sub-servicios separados por funcionalidades. (Cómo lo realiza Manuel en Estei).
• Utils: Considero que estamos abusando de las utils en los proyectos. Muchas veces creamos utils que solo se utilizan en un servicio específico y una sola vez. Considero que para esto se deberían manejar funciones internas en los servicios / sub-servicios que no sean parte del export de ese archivo.

La estructura de carpetas que considero podría funcionar para nuestros Backends, es la siguiente:

src
    assets
    components
        example-component-1
            example.routes.ts
            example.controller.ts
            example.dto.ts
            example.service.ts
            services
                find-examples.service.ts
                modify-examples.service.ts
                create-examples.service.ts
            utils
                example.util.ts
        example-component-2
        example-component-3
    middlewares
        example.middleware.ts
    utils
        error-handler.util.ts
        example-global.util.ts
    integrations
        twilio
            twilio.integration.ts
            twilio.dto.ts
        postmark
            postmark.integration.ts
            postmark.dto.ts
    models
        example.model.ts
    interfaces
        example.interfaces.ts
    types
        example.types.ts

[ChristianSanchez25]

Problemática actual:

Uno de los principales problemas que enfrentamos con la estructura de carpetas de nuestro backend es la falta de separación de responsabilidades. Estoy completamente de acuerdo con las observaciones y problemas que mencionó mi compañero Ricardo.

Propuesta 1: Estructura Modular

Para resolver estas problemáticas, propongo una estructura de carpetas modular que agrupe los componentes por funcionalidad en lugar de por tipo de archivo. De esta forma, cada módulo tendrá todo lo necesario para su funcionamiento (controladores, servicios, repositorios, rutas, etc.) en su propia carpeta. Esto facilitará el desarrollo y mantenimiento al tener una separación más clara y una organización más intuitiva.

Estructura de carpetas propuesta:

src/
├─ components/
│  ├── products/
│  │ ├── controllers/
│  │ │ └── product.controller.ts
│  │ ├── services/
│  │ │ ├── product-query.service.ts
│  │ │ ├── product-command.service.ts
│  │ │ └── index.ts
│  │ ├── dtos/
│  │ │ └── product.dto.ts
│  │ ├── repositories/
│  │ │ └── product.repository.ts
│  │ ├── routes/
│  │ │ └── product.route.ts
│  │ ├── interfaces/
│  │ └── product.interface.ts
├── common/
│ ├── middlewares/
│ ├── utils/
│ │ └── example.util.ts
│ ├── errors/
│ │ └── example.error.ts
│ ├── interfaces/
│ └── example.interface.ts
├── providers/
│ ├── twilio/
│ ├── stripe/
├── config/
└── server.ts

Ventajas

1. Separación modular: Cada módulo tiene su propio conjunto de controladores, servicios, repositorios, rutas, DTOs y interfaces. Esto facilita que cada desarrollador se enfoque en un módulo específico sin tener que navegar por carpetas que no son relevantes para su tarea.

2. Desacoplamiento de lógica de negocio: Al dividir los servicios en product-query.service.ts (lecturas) y product-command.service.ts (escrituras), logramos un mayor desacoplamiento y facilitamos el mantenimiento y escalabilidad del código.

3. Uso del patrón repositorio: Con el uso del patrón repositorio, desacoplamos la lógica de acceso a datos de la lógica de negocio. De esta forma, los servicios interactúan con los repositorios a través de interfaces, lo que permite que la lógica de la aplicación no dependa de la implementación específica de la base de datos. Esto también facilitaría el testing, ya que podemos mockear fácilmente los repositorios para pruebas unitarias.

4. Centralización de servicios externos: Las carpetas en providers/ permiten una integración clara y separada de servicios externos como Twilio y Stripe, centralizando la lógica de interacción con estos servicios en un solo lugar. Esto hace que las integraciones sean fáciles de mantener y reutilizar en otros módulos si es necesario.

5. Uso adecuado de utils y middlewares: Los utils y middlewares que son compartidos entre módulos se colocan en common/, evitando su inclusión en servicios específicos cuando no es necesario. Esto asegura un uso más claro y limpio de las funciones utilitarias.