La siguiente sección define las configuraciones que se deben tener presente en el desarrollo de los microservicios de la fábrica de desarrollo.

• Los microservicios deben aplicar las configuraciones definidas en la mayoria de los casos.
• Si un microservicio requiere configuraciones especiales, estas deben ser validadas con los lideres de desarrollo (Pablo Quintana, Daberson Henao, Carlos Torres, Gersain Castañeda).

Todo microservicio debe tener su configuración centralizada en el repositorio git definido en la fabrica, sin embargo existen situaciones donde un microservicio puede requerir configuraciones particulares. A continuación se definen los escenarios donde aplicarán cada tipo de configuración:

• Configuración de Registro y Descubrimiento (Cloud Config / Eureka)
• Configuración de Routing (Zuul)
• Base de Datos Centralizada

• Lógica del Negocio

Se define los siguientes tipos de archivos de configuración

• Configuración Centralizada: Archivos Yaml
• Configuración Local: Archivos Properties

• El nombre de la aplicación del microservicio debe ser definido de acuerdo al nombre exacto del paquete principal Ejemplo: co.ada.sicof.terceros
• El nombre del archivo de configuración centralizada debe ser bootstrap.yml
• El nombre del archivo de configuracion local debe ser application.properties
• Deben existir configuraciones por cada ambiente de despliegue en el repositorio de configuración y cada archivo de configuración debe indica el perfil los cuales son dev: desarrollo - test: QA - prod: producción Ejemplo: Microservicio: Terceros, Paquete Principal: co.ada.sicof.terceros, Nombre del Microservicio spring.application.name=co.ada.sicof.terceros, perfil de ambiente de despliegue de desarrollo: dev, Nombre del archivo de configuración: co.ada.sicof.terceros-dev.yml
• La creación de los archivos de configuración centralizada deben ser solicitados al administrador del repositorio de configuración (Pablo Quintana / Carlos Torres).

En la arquitectura propuesta es muy común que existan microservicios que proveen información y otros que la procesan, por esta razon hace necesario el conocimiento de las estructuras en la cuales se transportan los datos ya que en muchos escenarios persisten en el sistema. Teniendo presente esta situación recurrente se crea un domino de clases y entidades comunes donde se van a registrar todas la entidades que puedan ser requeridas por microservicios. A ontinuación se define las reglas a considerar para inlucir la entidades.

• Cada clase no debe tener lógica de negocio.
• Cada clase debe describir la estructura en su totalidad
• Cada clase debe estar agrupada según la estructura de definición de su parque principal teniendo presente que el nombre base empezará con la estrucutra base del domino de clases comunes Ejemplo: Para el microservicio co.ada.sicof.contabilidad.tercero su agrupación de entidades en el proyecto de dominio de clases de entidades comunes debe ser co.ada.models.sicof.contabilidad.tercero

←Volver atrás