DSL 1 - Presentando el DSL de Icon

Comenzamos considerando los datos. Los datos son lo que impulsa el procesamiento y la toma de decisiones a lo largo de IPF.

El primer concepto que consideramos, por lo tanto, es el "Business Data Elemento". Tiene cuatro propiedades:

Cualquier MPS El proyecto puede tener tantos elementos de datos comerciales diferentes como necesite. Estos elementos se definen dentro de un "Business Data "Library" que es simplemente una colección de datos empresariales relacionados y se pueden definir tantas bibliotecas de datos empresariales diferentes como sea necesario.

Dentro de la duración de un pago, cada elemento de datos comerciales es único y puede ser actualizado según sea necesario.

El procesamiento de un pago es realizado por un "Flow". Un flow representa un único proceso de negocio de principio a fin y está diseñado para especificar la duración de un único pago. Un solo flow puede tener múltiples caminos a través de él, cada uno representando una forma diferente de procesar un pago individual basado en los datos proporcionados para ese flow. Un flow contiene una serie de elementos:

Se discute una definición de cada uno de estos aspectos en las siguientes secciones.

Primero consideramos el "Global State Conjunto". El conjunto de estado global es un conjunto de estados que representan el estado general de un pago. Se utiliza particularmente cuando un pago puede abarcar múltiples flujos (por ejemplo, si el procesamiento del pago se divide en partes de "iniciación" y "ejecución"), pero también puede aplicar un estado de tipo agrupación general a las partes individuales del flujo para simplificar las transiciones de estado aparentes desde el nivel de pago. Cada estado a nivel de flujo puede ser mapeado a un estado global de tal manera que múltiples estados a nivel de flujo puedan ser considerados como si dejaran el pago en el mismo estado global general.

El siguiente concepto a considerar dentro de nuestro flujo es un "Estado". Este es, muy simplemente, un punto de descanso en el flujo por el que el pago puede pasar en su recorrido, así que, por ejemplo, podemos tener un flujo muy simple que va de " State A" a " State B".

Un estado en sí mismo tiene una serie de propiedades:

Cada flujo puede contener muchos estados diferentes.

Cuando un flujo se mueve de un estado a otro, esto se conoce como una "Transición de Estado". Dentro de IPF, para que ocurra una transición de estado, el sistema debe recibir un "Evento" en el proceso de pago. En este caso, se trata de un tipo específico de evento conocido como un "Dominio". Event_*. A domain event es un hecho persistente - La llegada de un evento significa que ha ocurrido algo explícito que puede causar algún tipo de cambio en el procesamiento de nuestro pago.

Un evento tiene una serie de propiedades:

Cuando se forma un evento, el sistema verificará su propio comportamiento para determinar qué acciones deben realizarse. Aunque este comportamiento se explorará más adelante en este documento, vale la pena señalar aquí que hay tres ocasiones en las que un evento puede causar un cambio en el procesamiento, las cuales se conocen como las condiciones de "Criterios del Evento" y se definen como:

Después de que se procese un evento, la aplicación puede realizar una o más actividades para determinar qué sucede a continuación con un pago. Por ejemplo, al recibir " Event Es posible que deseemos realizar alguna validación y llamar a otra aplicación para solicitarle que valide nuestros datos.

Para apoyar este procesamiento posterior al evento, el concepto más importante es el "Dominio Externo". Esto representa algún dominio empresarial.-no es el flujo actual de nosotros- con la que necesitamos interactuar.

Por ejemplo, supongamos que necesitamos comunicarnos con un sistema de sanciones durante parte del flujo. Para apoyar esto, modelaríamos ese sistema de sanciones como un dominio externo.

Cada dominio externo consiste en los tres tipos de interacción que podemos realizar con él:

Es posible que no deseemos tener que llamar a un dominio externo para continuar procesando nuestro flujo. Esto puede suceder porque sabemos qué hacer a continuación o podemos calcular qué hacer a continuación. Para esto, hay dos conceptos adicionales que debemos considerar:

En este caso, una opción es utilizar la capacidad de "Función de Dominio" que el flujo mismo ofrece. Funciona de manera muy similar a un par de solicitud / respuesta en una llamada a un dominio externo, excepto que en el caso de una función de dominio, el IPF application en sí mismo es un dominio, por lo que la llamada real permanece interna (considere, por ejemplo, crear un dominio externo que represente nuestro flujo actual-esto funcionaría de la misma manera que una función de dominio, pero sería una representación errónea de la lógica de control real). Por lo tanto, cuando llamemos a una función de dominio, esperaremos recibir una respuesta y luego esa respuesta se transformará en un evento que puede causar un procesamiento posterior.

Como una solicitud, la función de dominio tiene una serie de propiedades:

La segunda opción es un "Adicional Event- estos también pueden ser utilizados para mover el flujo.

Cuando se genera un evento adicional, el sistema lo procesará como si hubiera sido recibido en la aplicación a través de una instrucción o respuesta.

Añadamos estos a nuestro diagrama:

Sin embargo, ¿qué sucede si queremos realizar alguna lógica de manera condicional? Por ejemplo, puede que solo deseemos ejecutar un chequeo de fraude si el valor del pago supera las £50. En este caso, podemos utilizar un "Decision".

Una decisión nos permite realizar cierta lógica y luego tomar diferentes rutas de procesamiento posteriormente en función del resultado de esa decisión. Una decisión tiene una serie de propiedades:

Las decisiones en sí mismas se almacenan dentro de una "Biblioteca de Decisiones". Las bibliotecas son independientes del flujo y, como tal, la misma decisión puede ser utilizada en múltiples flujos.

Podemos utilizar una decisión en dos lugares:

Añadamos estos a nuestro diagrama:

Otra utilidad útil a considerar es la "Función Agregada". Una función agregada es un conjunto de lógica que puede ejecutarse al recibir un evento para realizar algún tipo de lógica sobre los datos recibidos. Estos datos se consideran "en tránsito" y, por lo tanto, no son persistidos por la aplicación.

Un buen ejemplo de esto es, por ejemplo, un contador que rastrea el número de veces que algo ha ocurrido durante un flujo.- cada vez que se llama a la función, podemos actualizar ese contador. El resultado de la función agregada se vuelve disponible a lo largo del flujo.

Otro buen caso de uso puede ser realizar un análisis de datos.mapping ejercicio para transformar los datos en algo que pueda ser utilizado posteriormente.

Añadamos la función de agregado a nuestro diagrama:

Los siguientes conceptos a considerar son ambos tipos de agrupamiento. Con el fin de separar la lógica, necesitamos definir cuándo procesar una entrada al sistema (de una respuesta o instrucción) y generar el evento a la lógica requerida al procesar el comportamiento real del sistema basado en ese evento. Contamos con dos conceptos de agrupamiento:

Lo siguiente a considerar son los segmentos reutilizables del flujo.

Por ejemplo, considere un chequeo de sanciones que puede ser requerido desde diferentes lugares dentro del flujo. Podríamos especificar cada sección del flujo por separado y escribir la lógica cada vez, pero idealmente nos gustaría poder reutilizar la lógica común cada vez. Aquí es donde se introduce el concepto de "Subflujo".

Un subflujo es un componente de flujo reutilizable. Es esencialmente lo mismo que un flujo en el sentido de que tiene estados, comportamientos de entrada y comportamientos de evento. Sin embargo, un subflujo no tiene vida propia y solo se utiliza como un mecanismo de reutilización y, por lo tanto, DEBE estar contenido dentro de un flujo externo. Al invocar un subflujo, su comportamiento es muy similar al de recibir un evento:

Lo clave que debe entender aquí es que, en lugar de moverse a un estado y luego llamar a una acción como en el procesamiento normal mencionado anteriormente, aquí nos movemos a un pseudoestado que actúa como un punto de entrada al subflujo. El "control" del flujo se transfiere entonces al subflujo; en este punto, procesará a través de las entradas y comportamientos de eventos hasta que alcance un estado terminal en el subflujo. Cuando alcanza un estado terminal, el control se devolverá al flujo que lo llamó con un resultado del nombre del estado terminal. Esto puede ser utilizado para el procesamiento posterior.

Tenga en cuenta que, para lograr la reutilización del subflujo en múltiples lugares, cuando un subflujo se coloca dentro de un flujo principal, su estado se mostrará como "<subflowid> <nombre del estado del subflujo>", donde <subflowid> es el nombre del pseudoestado del flujo que llama y <subflow state name> es el nombre del estado dentro del subflujo.

Finalmente, también es posible llamar directamente a un flujo desde otro. En este caso, el control se transfiere al flujo secundario, y esperamos un resultado de ejecución de vuelta. El flujo hijo puede informar que ha alcanzado cualquier estado de regreso al flujo padre. Más comúnmente, esto ocurrirá cuando se alcance un estado terminal y el flujo hijo haya terminado el procesamiento, pero también permite la retroalimentación del flujo hijo para estados intermedios antes de que finalice. Esto proporciona una oportunidad para pasar el control de un lado a otro entre el flujo hijo y el flujo padre según sea necesario.