DSL 14 - Uso de conceptos compartidos (Parte dos - Entre soluciones)
|
Comenzando
Este paso del tutorial utiliza como punto de partida la solución "shared_models_one" del proyecto. Si en cualquier momento quieres ver la solución de este paso, la encontrarás en la solución "shared_models_two". |
Un repaso rápido
En DSL 13 - Uso de conceptos compartidos (Parte uno - Dentro de una solución), extrajimos nuestra lógica de sanciones a un modelo separado. En la práctica, sin embargo, la mayoría de los proyectos se configuran como un servicio que proporciona una única solución. Por lo tanto, ahora necesitamos ver cómo importar modelos contenidos en soluciones reutilizables separadas.
La solución de Sanciones
Para este tutorial usaremos un módulo de sanciones preexistente. Este módulo contiene exactamente la misma lógica que construimos en las secciones anteriores de este tutorial, solo que empaquetada como una solución independiente y reutilizable.
El módulo de sanciones se construyó igual que el propio tutorial: usando el scaffolder.
Importar el módulo
La importación del módulo se realiza en la sección de plugins del pom dentro de nuestra aplicación.
Abramos nuestro proyecto principal del tutorial en IntelliJ y, si abrimos el pom de la carpeta mps (domain-root/mps/pom.xml), veremos que ya existe una entrada para el plugin maven-dependency como sigue:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>copy</id>
....Ahora solo necesitamos añadir una sección para desempaquetar (unpack) el módulo MPS de sanciones dentro de nuestra aplicación. Para ello añadimos una nueva ejecución como sigue:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>unpack-sanctions-plugin</id>
<phase>initialize</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>mps</artifactId>
<version>${sample-sanctions.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
<outputDirectory>${plugin_home}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
<execution>
<id>copy</id>Las claves aquí son el groupId, artifactId y version: es igual que cualquier otra dependencia Maven (nota: el artifactId aquí es el nombre de la solución).
Eso es todo lo que necesitamos añadir. Si quisiéramos añadir más soluciones, simplemente añadiríamos más bloques de ejecución, asegurándonos de introducir para cada uno el groupId, artifactId y version correctos, como haríamos con una dependencia Maven normal.
Usar el modelo remoto
Ahora que hemos configurado nuestra aplicación para importar el modelo, usémoslo. Primero reconstruiremos la aplicación para asegurarnos de que el módulo se descarga correctamente.
mvn clean installUna vez completado, abre MPS. Lo primero será eliminar el modelo de sanciones existente. Para ello, simplemente haz clic sobre él en el explorador y pulsa suprimir (delete). Aparecerá un cuadro de confirmación:
Pulsa el botón "delete files" ya que no necesitaremos los ficheros subyacentes, y pulsa "Delete".
Si ahora miras el flujo, verás errores donde llamamos al subflujo de sanciones, porque ya no tiene uno con el que trabajar.
Para resolverlo, pulsa Ctrl+R dos veces (o asegúrate de que la casilla esté marcada) y después busca y selecciona el Sanctions Subflow. Verás que, esta vez, proviene del modelo reutilizado:
Deberías ver cómo el error se resuelve al empezar a tirar del modelo recién importado. Si los errores no se resuelven automáticamente, sustituye las referencias al modelo antiguo por las del modelo recién importado.
Implementación en Java
El trabajo duro en esta parte de la serie lo hicimos arriba con las dependencias de MPS y la configuración de build. Desde el punto de vista de implementación Java, la única diferencia ahora es que el código de dominio de sanciones se ha generado en los módulos preexistentes. Así que aquí solo añadimos las dependencias a ipf-tutorial-app en el pom.xml, igual que antes:
<dependency>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>domain</artifactId>
<version>${sample-sanctions.version}</version>
</dependency>
<dependency>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>sampleapp</artifactId>
<version>${sample-sanctions.version}</version>
</dependency>|
La nueva importación del utilitario común tiene una estructura de paquetes ligeramente distinta, por lo que tendrás que reorganizar los imports de las clases SanctionsDomain en tu clase de configuración del tutorial. |
|
Aquí hemos añadido directamente las dependencias de los proyectos domain y sample app. Sin embargo, también podríamos tener un módulo separado que incluyera estas dependencias Y proporcionara una implementación para ellas. De hecho, el módulo de sanciones del tutorial hace esto con su paquete ipf-tutorial-sanctions-adapters. Si lo importásemos, podríamos eliminar nuestra declaración del bean SanctionsDomain y usar una solución completamente empaquetada (nota: hacerlo aquí también requeriría ejecutar el simulador de sanciones del que depende, por lo que se omite por ahora). |
Comprobación de nuestra solución
Como siempre, comprobemos ahora que nuestra solución funciona. Arranca la aplicación como antes (las instrucciones están disponibles en Revisión de la aplicación inicial si necesitas recordatorio).
Y luego podemos enviar un pago:
curl -X POST localhost:8080/submit | jqSi abrimos el pago en la GUI para desarrolladores y miramos el gráfico de nuestro flujo del tutorial (buscar por unit of work id, clic en view, clic en ipf tutorial flow, clic en view graph), veremos:
Si comparamos esto con el gráfico de DSL 9 - Uso de subflujos, podemos ver que todo es igual que antes y hemos extraído con éxito nuestro subflujo de sanciones a un modelo diferente que es completamente independiente de Ipftutorialmodel.