Documentation for a newer release is available. View Latest

Reutilización

En generation hablamos de los distintos elementos que se crean y de cómo se usan a nivel de modelo. Ahora, en esta sección, presentamos el concepto de reutilización.

La reutilización ocurre cuando tienes una pieza común de código de DSL que puede usarse en varios proyectos de flujos de IPF diferentes. Por ejemplo, considera un sistema de sanciones: muchos flujos distintos podrían querer interactuar con un sistema de sanciones, aunque esos flujos en sí no tengan conocimiento ni relación entre sí y puedan desplegarse por separado.

Una opción aquí sería crear un componente de DSL diferente que represente un sistema de sanciones en cada modelo y luego proporcionar muchas implementaciones separadas de este. Aunque es sencillo hacerlo, significaría mantener múltiples copias de esencialmente la misma capacidad y gestionar los problemas que esto probablemente introduciría. Aquí es donde entra la reutilización: la capacidad de que un modelo llame a una función en otro modelo.

En esencia es simple. Puedes importar una dependencia de un modelo a otro y luego referenciar los componentes del módulo compartido desde el núcleo. Un patrón típico para esto podría ser:

  • Modelo A: contiene un dominio externo que representa el sistema de sanciones.

  • Modelo B: contiene una implementación de flujo que quiere llamar al sistema de sanciones.

  • Modelo C: contiene una implementación de flujo que también quiere llamar al sistema de sanciones.

En este escenario, añadiríamos el modelo A como dependencia tanto del modelo B como del modelo C, permitiendo que B y C utilicen los mismos componentes definidos en el modelo A. A nivel de generación, cada uno de los modelos A, B y C será independiente y cada uno tendrá su propio ModelDomain que debe implementarse, lo que significa que toda la lógica para la implementación de la función compartida se mantiene separada y aislada. Luego, los modelos saben cómo comunicarse entre sí, por lo que solo necesitas implementar la lógica de sanciones en el Modelo A una vez, y entonces estará disponible para los modelos B y C simplemente importando una dependencia.

Pensemos cómo podría verse esto desde una perspectiva general:

reuse 1

Aquí podemos ver cómo podemos crear nuestros componentes de DSL personalizados y luego importar los componentes reutilizables como sanciones. El modelo reutilizable se implementa exactamente de la misma manera que los personalizados.