EST-DGT-001 Estándar para Nombres de Archivos de Código
v 3.0
Propósito
El objetivo de este documento es establecer un estándar para la nomenclatura de archivos en los proyectos de desarrollo de software que utilizan React Vite y Node con Express en Black Dot. Este estándar busca garantizar la consistencia y claridad en la estructura de los proyectos, facilitando la comprensión y el mantenimiento del código.
Notas introductorias
El correcto nombramiento de archivos es fundamental para la organización y la accesibilidad del código en los entornos de desarrollo, influyendo directamente en la eficiencia del trabajo en equipo y en la gestión de los repositorios de código de la organización.
Estándares
Nomenclatura para Frontend (React Vite)
Componentes: Los nombres de los archivos de componentes deben comenzar con mayúscula y terminar con la extensión .tsx, reflejando el nombre del componente. Ejemplo: AddButton.tsx.
Archivo base: El archivo base de cada directorio debe llamarse index.tsx.
Archivos TypeScript generales: Cualquier otro archivo .ts que no represente un componente debe estar nombrado en minúsculas. Ejemplo: constants.ts.
Nomenclatura para Backend
Estructura general
- Los nombres de los archivos deben seguir el formato
<modulo>.<capa>.ts, donde:
modulo: Representa el módulo principal al que pertenece el archivo, en minúsculas. Si el nombre del módulo consta de varias palabras, estas deben estar separadas por guiones. Ejemplos: value-object, user-management.
capa: Especifica la capa de aplicación del archivo, también en minúsculas. Posibles capas incluyen controller, service, repository, entity.
Ejemplo de nombre de archivo en backend: dummy.controller.ts.
- Cada módulo del proyecto debe estar organizado en directorios claves que encapsulan diferentes aspectos de la lógica de negocio en la carpeta de
src/.:
api/: Definición de rutas y controladores para la API REST.
controllers/: Contiene controladores para manejar las rutas HTTP.
routes/: Define las rutas de la aplicación usando Express.
middleware/: Funciones de middleware para manejar autenticación, errores y otras tareas transversales.
config/: Configuración de la aplicación, como por ejemplo: firebase-admin.config.ts
core/: Lógica de negocio y acceso a datos.
app/: Capa de aplicación que orquesta la lógica de negocio.
interfaces/: Define interfaces para implementaciones concretas.
services/: Contiene servicios que implementan la lógica de negocio.
__tests__/: Pruebas unitarias para los servicios.
domain/entities/: Define las entidades de dominio de la aplicación.
errors/: Define clases de errores personalizados.
common/: Define errores comunes para el uso general del proyecto.
infra/: Capa de infraestructura para interactuar con bases de datos y otros servicios.
mappers/: Transforma datos entre la base de datos y la lógica de negocio.
repositories/: Contiene clases de repositorio para acceso a datos.
utils/: Funciones y clases de utilidad que no pertenecen a un módulo específico.
enums/: Define enums de constantes utilizados en el proyecto.
-
Controladores
Los controladores deben seguir el formato
<nombre>.controller.ts.
Ejemplo:
controllers/
| user.controller.ts
| auth.controller.ts
- Rutas
Las rutas deben seguir el formato <nombre>.routes.ts.
Ejemplo:
routes/
| user.routes.ts
| auth.routes.ts
- Middleware
Los middlewares deben seguir el formato <nombre>.middleware.ts.
Ejemplo:
middleware/
| auth.middleware.ts
| error.middleware.ts
- Servicios
Los servicios deben seguir el formato <nombre>.service.ts.
Ejemplo:
services/
| user.service.ts
| auth.service.ts
- Repositorios
Los repositorios deben seguir el formato <nombre>.repository.ts.
Ejemplo:
repositories/
| user.repository.ts
| auth.repository.ts
- Mappers
Los mappers deben seguir el formato <nombre>.mapper.ts.
Ejemplo:
mappers/
| user.mapper.ts
| auth.mapper.ts
- Entidades
Las entidades deben seguir el formato <nombre>.entity.ts.
Ejemplo:
domain/entities/
| user.entity.ts
| auth.entity.ts
- Configuración
Los archivos de configuración deben seguir el formato <nombre>.config.ts.
Ejemplo:
config/
| firebase-admin.config.ts
- Pruebas Unitarias
Las pruebas unitarias deben seguir el formato <nombre>.service.test.ts.
Ejemplo:
services/**tests**/
| user.service.test.ts
| auth.service.test.ts
- Interfaces
Las interfaces deben seguir el formato <nombre>.interface.ts.
Ejemplo:
app/interfaces/
| user.interface.ts
| auth.interface.ts
- Errores
Las clases de errores personalizados deben seguir el formato <nombre>.error.ts.
Ejemplo:
errors/
| user.error.ts
| auth.error.ts
Control de cambios
| Versión | Cambio realizado | Análisis | Autor | Revisor(es) | Fecha de cambio |
|---|---|---|---|---|---|
| v 1.0 | Creación del estándar | N/A | Daniel Hurtado | Pendiente | 08/04/2024 |
| v 2.0 | Ajuste de formato | Se modificó el contenido del estándar de acuerdo a la plantilla porque el documento tenía información no requeridas | Yuna Chung | Ricardo Fernández | 23/04/2024 |
| v 3.0 | Actualización de estándar | Se agregó la nomenclatura para backend | Arturo Díaz | Ian Padrón | 30/04/2024 |