Repositorios
•	Los repositorios deben tener un archivo README.md que describa el propósito del proyecto, enlace a la documentación en Confluence si está disponible, y contenga las nuevas funcionalidades/cambios en cada versión.
Notas sobre Lombok
•	No usar @AllArgsConstructor, ya que al añadir un nuevo campo se altera el constructor existente (y equals y hashCode), lo que puede generar conflictos con otros desarrollos que usen la clase.
En su lugar, usar constructores explícitos con los campos necesarios o, mejor aún, @Builder.
•	Usar @Builder para clases modelo con más de 6 campos
Referencias:
Baeldung, Lombok Builder
•	Usar @Value en lugar de @Data para clases modelo para hacerlas inmutables, lo que reduce errores por modificaciones inesperadas.
Si el modelo va a ser deserializado, usar la anotación @JsonDeserialize, por ejemplo:
Añadir un test unitario para validar la serialización/deserialización.
Ejemplo:
CountryTest.java
•	No usar @Autowired y definir las propiedades de clase como final para facilitar los tests unitarios.
•	En los tests unitarios no basta con assertNotNull, hay que validar que los campos del objeto son los esperados.
•	No pasar parámetros por referencia en los métodos, sino copiar el objeto y devolver el nuevo valor para favorecer la inmutabilidad y la legibilidad. Define los parámetros como final.
•	Usar la API de streams de Java para bucles en lugar de for, while, do....
•	Aplicar el principio de responsabilidad única: una clase, una responsabilidad; un método, una responsabilidad. En la mayoría de los casos, una clase no debería tener más de un método público.
•	No definir interfaces si sabemos que solo habrá una implementación.
•	Las nuevas clases y funcionalidades deben tener tests unitarios.
•	Las clases tipo controlador deben testearse usando MockMvc para validar que la ruta y los parámetros definidos son correctos.
•	Segregación de interfaces:
Principio de segregación de la interfaz (Wikipedia)
•	En los tests unitarios usar el patrón Object Mother en lugar de archivos JSON
Object Mother (Martin Fowler)
Ejemplos: Java Design Patterns
•	No usar la cláusula default en switch-case.
Usar un enum, de forma que si se añade una nueva propiedad, el IDE marcará los switch que lo usan para que se les dé comportamiento.
Creación y eliminación de objetos
•	Usar métodos de fábrica estáticos en lugar de constructores.
•	Si un constructor tiene muchos parámetros, usar el builder.
•	Forzar los singleton a tener un constructor privado.
•	Preferir la inyección de dependencias en lugar de acceder directamente a recursos.
•	Evitar crear objetos innecesarios.
•	Eliminar referencias a objetos obsoletos.
Usar try-with-resources en lugar de try-finally.
Organización de paquetes
•	Usar la estructura:
en/bancamarch/<aplicación>/<funcionalidad>/<controller|service|repository|util|domain|model|...>
•	Extraer a una clase de utilidades aquellos métodos complejos tras un refactor.
El objetivo es que el paquete service contenga solo la funcionalidad “core” de los servicios.
Organización del código L3 con DDD (Domain Driven Design)
Dividir el código en tres paquetes:
•	infrastructure: cuando una clase es llamada por Temenos o invoca librerías externas.
•	application: solo lógica de negocio, sin dependencias de Temenos.
•	model: beans.