Desplegando Nuestro Primer Servicio de Dominio: `ms-catalog`

Jul 20, 2025 - 5 min read - 705 words

Con el registro central ms-services funcionando, es hora de desplegar nuestro primer microservicio de dominio. Empezaremos con un componente fundamental para la consistencia de los datos en toda la plataforma: ms-catalog.

ms-catalog es un microservicio diseñado para gestionar catálogos genéricos. Por el momento, su responsabilidad principal es la gestión de Tipos de Documento (TypeDocument), pero está diseñado para ser extensible a otros catálogos en el futuro. Al centralizar esta información, evitamos la duplicación y aseguramos que todos los demás microservicios hablen el mismo “idioma” cuando se refieren a entidades comunes.

En esta guía, seguiremos nuestro patrón de despliegue estándar:

Analizar la Arquitectura Interna: Entenderemos cómo está construido ms-catalog.
Configurar sus Secretos: Almacenaremos su configuración sensible en HashiCorp Vault.
Desplegar con Helm desde ArtifactHub: Usaremos su Helm chart público para instalarlo.
Verificar su Funcionamiento: Realizaremos una prueba de extremo a extremo.

Un Vistazo a la Arquitectura de `ms-catalog`

Aunque es un nuevo servicio, su ADN arquitectónico es idéntico al de ms-services, gracias a nuestro arquetipo base.

Flujo de la API a los Casos de Uso (CQRS)

Este diagrama muestra cómo una petición REST sobre la entidad TypeDocument se traduce en una acción interna.

Lado Izquierdo (REST): Muestra los endpoints estándar para las operaciones CRUD sobre TypeDocument.
Lado Derecho (Use Cases): La lógica real, separada por el patrón CQRS:
- Commands (Azul): CreateTypeDocument, UpdateTypeDocument, DeleteTypeDocument. Son operaciones que modifican el estado y emiten Eventos de Dominio.
- Queries (Amarillo): GetTypeDocument, GetAllTypeDocuments. Son operaciones de solo lectura, optimizadas para la consulta.

El Corazón del Dominio: El `TypeDocumentAggregate`

Este diagrama de clases nos muestra la estructura del Agregado TypeDocument, la pieza central de nuestra lógica de negocio según los principios de Domain-Driven Design (DDD).

El Agregado encapsula todos los datos y reglas de negocio para asegurar que un TypeDocument siempre se mantenga en un estado válido.

Despliegue y Configuración Paso a Paso

Configurando los Secretos en Vault ms-catalog necesita credenciales para conectarse a RabbitMQ, Redis y MongoDB. Almacenamos estos datos confidenciales en Vault bajo una ruta específica para este microservicio.
Terminal window
```
vault kv put -mount=inventory-keyvalue ms-catalogs `
  "RabbitMQ:UserName=<USERNAME_FROM_RABBITMQ_SECRET>" `
  "RabbitMQ:Password=<PASSWORD_FROM_RABBITMQ_SECRET>" `
  "Redis:Instances:Core:ConnectionString=<CONNECTION_STRING_FROM_REDIS>" `
  "Mongo:ConnectionString=<CONNECTION_STRING_FROM_MONGO_ATLAS>"
```
Podemos verificar que los secretos se han guardado correctamente en la interfaz web de Vault.

Desplegando con Helm desde ArtifactHub ms-catalog solo expone una API REST, por lo que solo necesitamos desplegar un Helm Chart.

Ver Chart en ArtifactHub: ms-catalogs-rest

Preparar el values-rest.yaml Local Creamos un archivo values-rest.yaml con la configuración de las variables de entorno no sensibles y la conexión a Vault.

# values-rest.yaml para ms-catalogs-rest
ms-base:
env:
    - name: RESOURCES__ENABLE
    value: "true"
    - name: RESOURCES__SERVER
    value: "http://ms-services-grpc.inventory.svc.cluster.local:5001"
    - name: SECURITY__VALIDISSUER
    value: "https://devcodedesignplus.ciamlogin.com/dfee7752-2c8a-4171-ad95-62ddc82d6ed8/v2.0/"
    - name: SECURITY__CLIENTID
    value: "305f759d-d1d2-467b-9eab-4a61389c7329"
    - name: SECURITY__VALIDAUDIENCES__0
    value: "305f759d-d1d2-467b-9eab-4a61389c7329"
    - name: RABBITMQ__HOST
    value: "rabbitmq-cluster.srv-rabbitmq.svc"
    - name: LOGGER__OTELENDPOINT
    value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"
    - name: OBSERVABILITY__SERVEROTEL
    value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"

vault:
    server: http://vault.vault.svc.cluster.local:8200
    solution: inventory
    token: ANGq0*B2acD1n5%F

virtualService:
    create: true
    namespace: istio-ingress
    hosts:
    - services.codedesignplus.app
    gateways:
    - istio-ingress/istio-inventory-gateway
    http:
    - name: ms-catalogs
    match:
    - uri:
        prefix: /ms-catalogs/
    rewrite:
        uri: /
    route:
    - destination:
        host: ms-catalogs-rest.inventory.svc.cluster.local
        port:
            number: 5000

Ejecutar el Despliegue con Helm Usamos helm upgrade --install para desplegar el chart. Como el namespace inventory ya existe, no necesitamos el flag --create-namespace.
Terminal window
```
helm upgrade --install ms-catalogs-rest codedesignplus/ms-catalogs-rest -f ./values.yaml --namespace inventory
```

Parte 3: Verificación del Despliegue

Verificar el Pod en Lens En Lens, bajo “Workloads > Pods”, ahora vemos nuestro nuevo pod ms-catalogs-rest corriendo en el namespace inventory.
Verificar el VirtualService de Istio El Helm chart ha creado automáticamente el VirtualService que enruta el tráfico desde nuestro Gateway. En Lens, bajo “Custom Resources > VirtualService”, podemos ver la nueva regla para ms-catalogs.
Probar el Acceso a la API
- Endpoint de Salud: La forma más rápida de verificar que el servicio está vivo es acceder a su endpoint de salud. Abre un navegador y ve a: https://services.codedesignplus.app/ms-catalogs/health/ready
  
  Deberías ver una respuesta “Healthy”.
- Swagger UI: Para explorar la API de forma interactiva, podemos usar la interfaz de Swagger UI, que viene integrada en el microservicio. Navega a: https://services.codedesignplus.app/ms-catalogs/index.html
  
  Aquí puedes ver todos los endpoints disponibles para TypeDocument y probarlos directamente.

Conclusión

Has desplegado con éxito tu primer servicio de dominio, ms-catalog, siguiendo el patrón estandarizado del ecosistema CodeDesignPlus. Este proceso —configurar secretos en Vault, personalizar un values.yaml y ejecutar helm upgrade --install— es la plantilla que repetiremos para dar vida al resto de los microservicios.

Con ms-services como registro y ms-catalog gestionando nuestros datos maestros, estamos sentando las bases de una aplicación robusta y bien organizada. En el próximo artículo, continuaremos expandiendo las capacidades de nuestra plataforma.