Nomenclatura para los Servicios de Spin - Mirror Strategy

Se recomienda que se documente el código mediante JavaDocs, en el siguiente link podemos checar como usar JavaDocs con IntelliJ.

Se propone la siguiente nomenclatura para ser implementada en los proyectos de Spin - Mirror Strategy:

Para todo objeto que se cree en los proyectos se deberá de respetar la siguiente nomenclatura:
{{objectType|function}}. Esto solo aplicaría para funciones/métodos o clases auxiliares que ayuden en el desarrollo, ejemplo:
// Donde 'balance' es el dominio y 'Transfer' es el objectType o function public transfer(){}
para el nombrado de variables y/o parámetros, estos deben de tener nombres relacionados al dominio. Se debe de evitar en lo mayor posible dar nombres a variables o parámetros que no sean del dominio o que su significado sea confuso o ambiguo, ejemplo de un nombre incorrecto de una variable:
public class BalanceDTO { // esta propiedad es incorrecta ya que no da significado en el dominio y puede // generar confusión al usarla o invocarla private x; // esta propiedad de igual forma es incorrecta porque no pertenece al // dominio private myVariable; // esta propiedad es correcta ya que puede pertenecer al dominio y da un // significado coherente a su uso private availableCredit; // esta propiedad es incorrecta ya que aunque pertenece al dominio, no es // muy clara su usabilidad o momento de invocación private userAmounts9; }

Nota: se usará camelCase para el nombrado de variables, parámetros, métodos/funciones y/o propiedades. Revisar el
documento de Mejores prácticas de Desarrollo

Nomenclatura para el nombrado de DTOs

Nombre de la clase DTO: El nombre de la clase DTO debe reflejar los datos que contiene. Puedes utilizar un
sustantivo en singular o plural que represente el concepto de los datos transferidos. Por ejemplo, si estás
transfiriendo información de usuarios, puedes llamar a la clase "UserDTO" o "UserDataDTO".

Atributos: Los atributos de la clase DTO deben reflejar los datos que se están transfiriendo. Utiliza nombres
descriptivos que sean claros y concisos. Puedes seguir las convenciones de nomenclatura de Java, como el uso de camelCase para nombres de variables. Por ejemplo:

public class UserDTO {
    private String firstName;
    private String lastName;
    private String email;
    // ...
}

Métodos: Los DTO suelen ser estructuras de datos simples y no tienen mucha lógica asociada. Por lo tanto, no es necesario añadir métodos más allá de los métodos getter y setter para acceder a los atributos. Sin embargo, si se necesita realizar algún procesamiento adicional, puedes agregar métodos apropiados según tus necesidades.

Nomenclatura para el nombrado de URIs

La nomenclatura a utilizar en el nombrado de las URI's serán las siguientes (se validó con Spin):

En el nombrado de las URIs debe ser en plural, no en singular para el manejo de diferentes tipos de recursos.
Ejemplos:
POST - /accounts/blocks
GET - /accounts/balances
Agregar el tema de versionado de las APIs de manera mandatoria en la URL
Ejemplos:
POST - /v1/accounts/blocks
GET - /v1/accounts/balances
Se debe usar camelCase para el nombrado de atributos y parametros
Ejemplos:
GET - /v1/accounts?idUser=11
POST /v1/accounts {"idUser": 11}
Si se tiene más de una palabra en la url, se debería usar el caso spinal-case.
Ejemplos:
POST - /v1/specfic-salaries

Account Mirror

Se podrían modificar lo siguientes endpoint como se muestra a continuación:

/account/details => /v1/accounts/details
/account/block-code => /v1/accounts/blocks

Nota: para la definición de URI's de servicios, se recomienda utilizar lowercase y seguir la nomenclatura de
/{{domain}}/{{subaction ó subobject}}

Balance Mirror

Se podría modificar los siguientes métodos que se enlistan a continuación:

/account/balance => /v1/balances
/account/balance/details => /v1/balances/syncs
/account/FL-balance => /v1/balances/transfers
/account/FL-transferP2P => /v1/balances/transfers-p2p
/account/QRFL-balance => /v1/balance/transfers-qrfl

Nota: Estas son propuestas para dejar más desacopladas las funciones o métodos de un proveedor externo, en caso de que
queramos ganar más claridad en la implementación de los servicios a desarrollar, se propone reutilizar la nomenclatura
que se tiene hoy en día.

Nomenclatura para el resto de Objetos de desarrollo

Para el nombrado de objetos de tipo Repository o Service la nomenclatura propuesta es la siguiente:
{{Domain}}{{SubAction|SubObject}}Repository.java o {{Domain}}{{SubAction|SubObject}}Service.java
(se usará UpperCamelCase).

NOTA para SubAction o SubObject se hace referencia a componentes que son parte del dominio, ya sean acciones
que se pueden realizar en el mismos u objetos que forman parte del mismo. Ejemplo AccountUpdate donde el dominio es
Account y el SubAction o SubObject sería Update