Para el tema de microservicios, al menos el core de ellos, se desarrolla en capas.

Estos microservicios aún no contemplan

capa de autenticación, circuit breaker o alguna capa de seguridad.

El desarrollo de microservicios busca desacoplar, distribuir toda la lógica compleja de un sistema en pequeños módulos
independientes pero que trabajan conjuntamente para un propósito en común. Los microservicios comúnmente son
consumidos por algún cliente, el cual puede ser un frontend o incluso otro microservicio.
Un microservicioS tiene una responsabilidad única (un alcance delimitado, un ámbito).

Vamos a partir del siguiente esquema de DB, que mapea las entidades de un hospital.
En este caso, para propósitos de práctica, crearemos un microservicio para cada tabla, pero si este fuera un esquema
más grande que reflejara la complejidad de un negocio más grande (cualquier proyecto empresarial), todas estas tablas
estarían siendo afectadas por un solo microservicio, dado que son catálogos.

Para entender un poco más, esquematizaremos lo que se pretende construir.

Definiremos un proyecto base, el cual contendrá 3 de las 7 capas contempladas. Este proyecto sirve de staff para todos
los demás microservicios que estaremos definiendo. Este proyecto NO estará corriendo en el servidor.

PRIMER PASO

Ingresamos a https://start.spring.io para configurar nuestro proyecto springboot. Esta configuración también se puede
realizar desde dentro del ide, pero la interface web se presenta más sencilla.
Para este proyecto base se realizará la siguiente configuración:
Project: Maven Project
Languaje: Java
SpringBoot: 2.4.10 (escoger alguna que no tenga SNAPSHOT, M2 o alguna anotación.)

Metadata:
Group: com
Artifact: ms-persistence
Name: ms-persistence
Packaging: Jar
Java 8

Dependencias:
Spring Data JPA
Oracle Driver (en el caso de utilizar una db Oracle, si no, buscar el correspondiente)
SpringBoot DevTools

Estas dependencias son únicamente para la conexión a DB y el uso del modulo JPA.
En este punto damos clic a GENERATE, esto nos descargará un paquete comprimido que contiene nuestro proyecto
configurado.

SEGUNDO PASO

Entonces, ¿Como es que están desacoplados?

Descomprimir el paquete, esa carpeta ponerla en el workspace del IDE. Después es necesario abrir el IDE para
importarlo.

File->Import->Maven->Existing Maven Projects->Next->Browse->Buscar la carpeta en el explorador, solo seleccionar la

carpeta NO ingresar a ella.
Esta es la pantalla que deberíamos ver:

El archivo pom.xml nos indica que si reconoció el proyecto, clic en Finish para terminar de importarlo. Después de eso,
Maven estará construyendo la estructura del proyecto en nuestra máquina, la primera vez esto puede tomar un tiempo
considerable, esperar un poco.

¿Qué cosa es Maven?

Su principal función es gestionar dependencias, es decir, ser el medio por el cual podamos agregar, modificar o eliminar
dependencias según las necesidades del proyecto. Pero en realidad maven posee muchas mas funcionas, compilar
proyectos, generar jars, etc.
El archivo que maven escanea cada que va modficar las dependencias es el pom.xml
TERCER PASO

Al terminar de construir el proyecto, la estructura es la siguiente:

Desplegamos la carpeta src/main/java:

Vemos que ya existe un paquete por default, com.mspersistence. Tomando como base esa nomenclatura, definiremos 3
paquetes más, entitys, repositorys y request.
Es importante que se siga EXACTAMENTE esa nomenclatura, es decir, los paquete conserven el nombre
base(com.mspersistence) y posteriormente diferenciarlos(entitys, repositorys, request).
De otro modo, el proyecto no encontrará las clases aunque nosotros si las podamos ver.

Nuestra estructura de paquetes debe quedar de esta manera:

CUARTO PASO
Pero hay un problema, si desplegamos el paquete com.mspersistence veremos que dentro hay una clase llamada
MsPersistenceApplication.java la cual contiene el método main:
Esta clase deberemos eliminarla por una sencilla razón: este proyecto estará conectándose con los demás
microservicios, esto crearía una estructura donde habría más de un método main presente y recordemos que en
cualquier aplicativo Java sólo debe existir un método main en todo el aplicativo.

De modo que el proyecto debe quedar así:

Como ves, la estructura
del proyecto sigue
intacta, solo se ha
eliminado la clase antes
mencionada y por lo
tanto su paquete.

QUINTO PASO

Empezaremos a colocar las clases e interfaces necesarias en sus respectivos paquetes. Crearemos una clase llamada
Paciente. Es importante señalar que los nombres de las clases en Java siempre comienzan con su primer letra
mayúscula.
En el paquete repository, creamos una interface llamada PacienteRepository:

Por último, crearemos también una clase en el paquete Request, llamada PacienteRequest.
Nuestro proyecto debe verse ahora así:
SEXTO PASO – MAPEO DE ENTIDADES

Las entitys en Java son clases que mapean (es decir, reflejan o modelan) una tabla en concreto de base de datos, estas
clases contienen un atributo de clase por cada columna de la tabla en db y además de una anotación que le indica a JPA
como va a procesar esa columna con el atributo, además de otras situaciones particulares.

Veamos lo que la tabla Pacientes contiene en la base Oracle:

Cada columna de la
tabla tiene un nombre y
una definición (tipo de
dato)

Hay que considerar también que al menos en Oracle, la generación de id’s en las tablas se hacen por medio de una
secuencia , la cual también debe estar mapeada en la entidad. De modo que el mapeo quedaría así:
ANOTACIONES DE JPA

@Entity Convierte un POJO (una clase común) en una entidad

@Table Le indica a JPA que tabla de la DB estará modelando esta
entity
@Id Indica que atributo de la entidad será tratado como llave
primaria
@GeneratedValue Indica como se estará generando los ids en la entidad,
setea un nombre de generador
@SequenceGenerator Recupera el nombre del generador, enlazado a una
secuencia existente en db.
@Column Le dice a JPA que ese atributo estará enlazándose con
una columna específica de la tabla.

Al empezar a colocar las anotaciones, es normal que inmediatamente el IDE no sepa de donde importarlas. Basta con
esperar unos segundos para que esto suceda.

Esto agregara una línea nueva en la sección de los imports (ubicada en el tope de la clase)

Si sigue sin reconocerlas, entonces debemos ejecutar una serie de pasos a fin de que nuestro gestor de dependencias
reescane todas las clases y librerías.

Clic derecho al proyecto (no a los paquetes)

1.Refresh
2.Build Project
Si la opción Build Project no aparece, ir a:
 Desmarcar la casilla Build Automatically
Despues, ejecutar Update Maven Project
Después de esto, ya debería ser posible importar nuestras dependencias. La entidad estará formada únicamente por
este mapeo de atributos y por los getters y setters de cada atributo.

SEPTIMO PASO – INTERFACE DE ACCESO A DATOS

Ahora debemos configurar la interface que se encargará de llevar y traer datos de la db por medio de JPA

El extends realiza la herencia de toda la funcionalidad

que nos ofrece JPA, de modo que ya no tenemos que
estar creando consultas manualmente.
La interface JpaRepository necesita ser parametrizada
con la entity que estará trabajando y el tipo de dato
que tiene el atributo anotado con @Id en esa misma
entity.

La anotación @Repository también es de JPA, y esto

convierte a la interface PacientesRepository en un DAO (Data Acces Object).

Si dentro de los métodos de JPA no encontramos alguno que cumpla nuestras necesidades, podemos crear consultas
personalizadas con la anotación @Query, pero esto lo veremos mas adelante según se vaya necesitando.

OCTAVO PASO – OBJETO REQUEST

Las clases request son POJOS que modelan las objetos

que llegan desde el frontend o cualquier entidad que
los consuma.
Son básicamente una entity, pero sin las anotaciones,
por lo tanto en nuestra arquitectura no están
haciendo referencia a alguna entity.
Es importante incluir en estas clases un método
constructor vacío , además de los getters y setters.
El metodo toString es opcional.
 MS-PACIENTES
Para el microservicio de pacientes, se configura de la misma manera que el anterior, pero con unas dependencias extras:

Las dependencias extras son para la construcción de los servicios rest con JAX-RS y tomcat como servidor de
aplicaciones.
Se realizan los mismos pasos, generar el comprimido, descargarlo, descomprimir en el workspace e importarlo al IDE.
Nuestro proyecto debería tener una Del mismo modo que el estructura como la siguiente:
anterior proyecto, se crearán 4
paquetes con distinto nombre,
conservando la nomenclatura
del paquete default:
service
serviceImpl
controllers
exception

En este caso, el paquete

default(com.pacientes) no se
eliminará ni su clase, en cambio
se realizará una configuración
adicional.

NOVENO PASO – CONFIGURAR UBICACIÓN DE REPOSITORYS Y ENTITYS

Se agregarán 2 anotaciones:
@EnableJpaRepositories: Sobreescribe la configuración por default de
JPA por la que nosotros le pasemos como argumento.
@EntityScan: Le indica a JPA en qué paquete debe buscar los entitys
con los que estará trabajando. Estructura del proyecto persistence

En este punto, ya estamos referenciando código de un proyecto dentro de otro, las capas de entidades y acceso a datos
estarán únicamente en el proyecto de persistencia. Estás serán consumidas por todos los demás microservicios y para
esto, hace falta hacer la inyección de dependencia del persistence hacia pacientes, en este caso.
Para tal motivo, es necesario abrir el archivo pom.xml de los 2 proyectos:

Etiqueta de cierre de la dependencia

anterior

Etiqueta de apertura de dependencia

Datos de la dependencia

Etiqueta de cierre de dependencia

Etiqueta de cierre de la sección de

dependencias

Lo que se realizó aquí fue integrar como una dependencia más, todo el proyecto persistence dentro del pom del
proyecto pacientes, indicándole el groupId, artifactId y versión del persistence dentro de llaves de dependencia.

Esto es la llamada inyección de dependencias.

DECIMO PASO – INTERFACE DE NEGOCIO

Esta interface contiene las acciones particulares de cada lógica de negocio, por lo regular son procesos complejos que
utilizan dentro de sí las acciones definidas por JPA. En este ejemplo sencillo, se trata únicamente de las acciones básicas
de cualquier CRUD, pero en realidad esta capa tiene que ver más con los procesos propios de cada negocio.
Recordemos que en las interfaces solo se enlistan las acciones a realizar sin darles lógica, es decir, quedan como
métodos abstractos. La lógica se les da en aquellas clases que implementen estas interfaces.

Ahora, observa como al posicionar el cursor sobre el error marcado en la línea 12, la ayuda del IDE identifica un paquete
com.persistence.entity. Tal paquete es la capa de entitys del proyecto persistence, el proyecto que se conectó.
Entonces, el configurar las anotaciones @EnableJpaRepositories, @EntityScan y la respectiva inyección de
dependencias en los pom hizo posible que el IDE sepa de donde tomar ciertas clases que en el proyecto pacientes no
existen.
DECIMO PRIMER PASO – CAPA DE IMPLEMENTACION

Esta capa del microservicio es donde se encuentran todas las capas anteriores. Nótese entonces que las demás capas
estuvimos construyendo los distintos objetos y relaciones que nos servirán en esta capa para poder trabajar con objetos
que mapean tablas de base de datos y operaciones dadas por JPA, además de objetos de respuesta.

Implementamos la interface PacienteService

Traemos sus métodos

Aquí tenemos ya los métodos de la interface PacientesService, la entidad Pacientes y el PacientesRequest.
Debemos ahora traer la interface de acceso a datos, PacientesRepository mediante inyección de dependencias con la
anotación @Autowired
Utilizando los métodos que nos brinda la interface anterior y las excepciones, le daremos lógica a cada operación de
negocio.
@Override Esta anotación indica sobreescritura. Los métodos que la
tienen no son nativos del lugar donde están, sino que
vienen de otro lugar (otra clase u otra interface)
@Autowired Con esta anotación realiza la inyección de dependencias
dentro de la capa de implementación.
@Service
.findAll() Devuelve una lista de elementos del tipo que se
parametrizó el repository
.existById() Verifica si existe un registro pasándole como parámetro
el id, devuelve verdadero – falso
.findById() Busca un objeto por id, devuelve un Optional
.get() Nos ayuda a extraer el objeto que viene dentro del
Optional
.save() Guarda la entity que se le pase como parámetro.
.deleteById() Elimina el registro indicado con el Id que se le pasa como
parametro

DECIMO SEGUNDO PASO – CAPA DE CONTROLADOR

Esta capa sirve de

enrutador para las
distintas peticiones
que lleguen al
microservicio, se crean
endpoints que mapean
cada petición con un
path especifico y un
verbo http con el cual
responder.
 @RestController Indica que esta clase es un controlador que trabaja con
las especificaciones de REST
@RequestMapping Setea el path general de la clase, será usado para formar
los endpoints
@Autowired Expone la funcionalidad de la capa anterior (service)
junto con la lógica
@GetMapping Configura el endpoint para que responda con verbo GET
@PostMapping Configura el endpoint para que responda con verbo POST
@PutMapping Configura el endpoint para que responda con verbo PUT
@DeleteMapping Configura el endpoint para que responda con verbo
DELETE
@RequestBody Habilita la recepción de parámetros dentro del body de
la petición, mapeados con el objeto request
@PathVariable Indica que se recibirán parámetros en la URL del
endpoint, mapeándolos a una variable que java puede
manejar.

Cada anotación que aquí ves, el IDE te dirá de donde importarlo. Si no fuera asi, debes actualizar el proyecto.
Clic derecho al proyecto, Refresh, Build Project, después Maven->Update Project.