DSL 1 - Presentando el DSL de Icon

Comenzamos considerando los datos. Los datos son lo que impulsa el procesamiento y decision-realización 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 tantas diferentes business data elementos según sea necesario. Estos elementos están definidos dentro de un "Business Data Biblioteca" que es simplemente una colección de relacionados business data y tantos diferentes business data Las bibliotecas pueden definirse según sea necesario.

Dentro de la duración de un pago cada business data el elemento 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 Set". El global state el conjunto es un conjunto de estados que representan el total state 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 tipo de agrupación general.state a las partes individuales del flujo para simplificar lo aparente state transiciones desde un nivel de pago. Cada nivel de flujo state puede ser mapeado a un global state de manera que múltiples estados de nivel de flujo puedan ser considerados para dejar el pago en el mismo global general state.

El siguiente concepto a considerar dentro de nuestro flujo es un "Estado". Esto es muy simplemente un resting punto 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".

A state tiene una serie de propiedades:

Cada flujo puede contener muchos estados diferentes.

Cuando un flujo se mueve de uno state a otro, esto se conoce como una "Transición de Estado". Dentro de IPF, para un state la transición debe ocurrir, entonces el sistema necesita recibir un "Event" en el proceso de pago. En este caso, es en realidad un tipo específico de event conocido como un "Domain Event". A domain event es un hecho persistente-la llegada de un event significa que ha ocurrido algo explícito que puede causar algún tipo de cambio en el procesamiento de nuestro pago.

An event tiene una serie de propiedades:

Cuando un event se forma, entonces 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 event puede causar un cambio en el procesamiento, estos se conocen como las condiciones de "Criterios de Evento" y se definen como:

Después de un event se procesa, la aplicación puede entonces realizar una o más actividades para determinar qué sucede a continuación con un pago. Así que, por ejemplo, al recibir " Event Podemos desear realizar alguna validación y llamar a otra aplicación para solicitarle que valide nuestros datos.

Para apoyar esta publicación-event procesamiento, 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 será transformada en un event lo 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 un adicional event se eleva, 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 es superior a £50. En este caso, podemos utilizar un "Decision".

A decision nos permite realizar cierta lógica y luego tomar diferentes rutas de procesamiento posteriormente basadas en el resultado de eso decision. A decision tiene una serie de propiedades:

El decisions se almacenan dentro de una "Biblioteca de Decisiones". Las bibliotecas son independientes del flujo y, como tal, la misma decision puede ser utilizado en múltiples flujos.

Podemos utilizar un decision en dos lugares:

Añadamos estos a nuestro diagrama:

Otra utilidad útil a considerar es el "Aggregate Function". An aggregate function es un conjunto de lógica que puede ser ejecutado al recibir un event 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 aggregate function entonces se vuelve disponible más adelante en el flujo.

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

Agreguemos el aggregate function a nuestro diagrama:

Los siguientes conceptos a considerar son ambos tipos de agrupamiento. Para separar la lógica, debemos definir cuándo procesar una entrada al sistema (de una respuesta o instrucción) y generar el event a la lógica requerida al procesar el comportamiento real del sistema basado en eso event tenemos dos conceptos de agrupación:

Lo siguiente a considerar son los segmentos reutilizables del flujo.

Por ejemplo, considere una verificación de sanciones que puede ser requerida 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,input behaviours y event behaviours. 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 llamar a un subflujo, es muy similar en comportamiento a recibir un event:

La clave que debe entender aquí es que en lugar de moverse a un state y luego llamando a una acción como el procesamiento normal anterior, aquí pasamos a un pseudo-state que actúa como un punto de entrada en el subflujo. El "control" del flujo se transfiere entonces al subflujo, en este punto procesará a través de la entrada y event behaviours hasta que alcance un terminal state en el subflujo. Cuando alcanza un terminal state, el control se devolverá al flujo que llama con un resultado del nombre del terminal state. 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, es state’s se mostrará como "<subflowid> <subflow state "name>" donde <subflowid> es el pseudo-state nombre del flujo de llamada y <subflujo state name> es el nombre del state 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 state volver al flujo principal. Más comúnmente, esto será cuando un terminal state se alcanza y el flujo secundario ha terminado de procesar, pero también permite la retroalimentación del flujo secundario para estados intermedios antes de que finalice. Esto proporciona una oportunidad para pasar el control de un lado a otro entre el flujo secundario y el flujo principal según sea necesario.