[IPL-228] Refactor objetos customers

[afalla-conekta]

Detalle del PR

Cambio de los objetos de (Objetos paginados y listas) en la entidad Customer para independizar del objeto customerReq

Descripción

• Cambio en atributos de tipo Object en la clase Customer
• Ajustes y creación de Test unitarios
• Se añade archivos moks .json para funcionamiento de test unitarios
• Ajustes en scaffoding para Order debe ser una entidad y no dentro de paquete response (Eliminado)

Tarea/Issue relacionada con JIRA

IPL-228

Motivación y Contexto

El código mas coherente y mejorar la discriminación de los atributos del objeto ordenes para quienes usen posteriormente la libreria

Tipos de Cambios

• Cambio en la documentación / refactorización / actualización de dependencia
• Corrección de errores (cambio que soluciona un problema)
• Nueva característica (cambio que agrega funcionalidad)
• Cambio de comportamiento (corrección o característica que cambiara la funcionalidad existente)

Checklist

• Mi código sigue el estilo de codificación de proyecto.
• Mi cambio requiere un cambio en la documentación.
• He actualizado la documentación correspondiente.
• Agregue los tests para cubrir mis cambios.
• Todos los test nuevos y existen pasaron correctamente.
• Actualice el changelog.

Evidencias

Convención de merge

Este repositorio usa Gitflow

Branch desde	Branch hacia	Merge commit	Squash and Merge
feature/	develop	❌	✅
hotfix/	master - release/	❌	✅
fix/	release/x.x.x	❌	✅
release/x.x.x	master	✅	❌
backport/	develop	✅	❌

¿Qué pasa si hago merge commit cuando debía hacer un squash?

• Nada grave, simplemente nos estaríamos llevando commits innecesarios al branch donde mergeemos, ejemplo, si en mi branch feature/ tengo 15 commits y los comentarios no son descriptivos (fix, fix tests, working) me estaría llevando todos esos a develop, cuando con el Squash voy a llevar uno solo.

¿Qué pasa si hago Squash cuando debía hacer un merge commit?

• En este caso no estaríamos cumpliendo la función que esperamos que es llevar los commits de un branch a otro para emparejarlos, por ejemplo, cuando mergeamos una release a master, el objetivo es dejar parejos develop y master, y si usamos squash como estrategia de merge van a seguir teniendo commits distintos, por lo que en el siguiente release podríamos tener conflictos.

---

[matiasrosemberg]

No veo nada fuera de lugar. Buen trabajo.