En proyectos de gran escala, identificar rápidamente el tipo de una clase facilita la comprensión del código, la colaboración y la depuración. Sin un esquema de nombres estandarizado, es común que los desarrolladores enfrenten dificultades al interpretar la funcionalidad de una clase solo por su nombre, lo que ralentiza el mantenimiento y el desarrollo. En entornos profesionales, donde múltiples equipos trabajan sobre el mismo código base, contar con una nomenclatura clara mejora la comunicación y reduce la posibilidad de errores. Para solucionar esto, se propone una convención de nombres basada en prefijos y sufijos que permita diferenciar los distintos tipos de clases en Java.

Para garantizar la claridad, adoptamos las siguientes reglas:

• Prefijos:
  • Enumeraciones: E (Ejemplo: EUserRole)
  • Interfaces: I (Ejemplo: IUserService)
• Sufijos:
  • Entities (Ent): Representan objetos persistentes. Ejemplo: UserEnt
  • Value Objects (VO): Objetos inmutables con valor significativo. Ejemplo: MoneyVO
  • Data Transfer Objects (DTO): Transporte de datos entre capas. Ejemplo: UserDTO
  • Repositories (Repo): Acceso a datos. Ejemplo: UserRepo
  • Services (Svc): Lógica de negocio. Ejemplo: UserSvc
  • Controllers (Ctrl): Gestionan solicitudes HTTP. Ejemplo: UserCtrl
  • Exceptions (Ex): Manejo de errores. Ejemplo: InvalidUserEx
  • Configuration (Cfg): Configuraciones de aplicación. Ejemplo: DatabaseCfg
  • Utility (Util): Métodos reutilizables. Ejemplo: DateUtil
  • Test (Test): Clases de prueba. Ejemplo: UserSvcTest
  • Commands (Cmd): Acciones en el sistema. Ejemplo: CreateUserCmd
  • Domain Events (Evt): Eventos de dominio. Ejemplo: UserCreatedEvt
  • Validation (Val): Validaciones. Ejemplo: UserVal
  • Adapters (Adp): Integraciones con otros sistemas. Ejemplo: ExternalServiceAdp
  • Message Brokers (Brk): Comunicación con colas de mensajes. Ejemplo: KafkaMsgBrk
  • Mappers (Map): Transformación de objetos. Ejemplo: UserMap
  • Views (View): Modelos de presentación. Ejemplo: UserView
  • Gateways (Gtw): Comunicación con servicios externos. Ejemplo: PaymentGtw
  • Factories (Fct): Creación de objetos. Ejemplo: UserFct
  • Specifications (Spec): Criterios de búsqueda. Ejemplo: UserSpec
  • Middleware (Mid): Interceptores de solicitudes. Ejemplo: AuthMid
  • Aggregates (Agg): Raíces de agregados DDD. Ejemplo: OrderAgg
  • Use Cases (UC): Casos de uso específicos. Ejemplo: RegisterUserUC
  • Queries (Qry): Consultas a la base de datos. Ejemplo: FindUserQry
  • View Models (VM): Modelos de datos para UI. Ejemplo: UserVM
  • Policy / Guard (Pol o Grd): Reglas de negocio. Ejemplo: UserAccessPol

Para aplicar esta convención en un proyecto, recomendamos documentarla dentro del repositorio, integrar validaciones automáticas en las revisiones de código mediante linters o revisiones de PR y aplicar la convención en nuevos desarrollos, refactorizando el código legado progresivamente.

Adoptar una convención de nombres en clases Java mejora la comprensión del código y la colaboración en equipos de desarrollo. Al estandarizar prefijos y sufijos, cada clase tiene un propósito claro y es más fácil de ubicar y utilizar. Implementar esta convención desde el inicio de un proyecto o refactorizar el código existente progresivamente traerá beneficios a largo plazo.