WCF – Decisión de parámetro de diseño

Estoy diseñando un servicio para FundManagement. El Servicio de gestión de fondos tiene una operación denominada “UpdateFundApprovalDate (Fondo de FundDTO)”. Esta operación actualizará el registro de la tabla de fondos con la fecha de aprobación para el ID de financiamiento. El servicio será utilizado por un cliente “FundManagementUI”.

Existe una regla de negocio de que la fecha de aprobación no debe actualizarse si la renovación del contrato está en curso.

Hay un Servicio de Renovación por separado. El servicio de renovación utiliza datos de la tabla de renovación (que tiene ID de financiación). La tabla de estructura de renovación es (RenewalID, FundingID, RenewalStartDate, Renewal CompletionDate, RenewalStatus). Hay una operación de servicio llamada “public List GetInProgressRenewal (FundDTO Fund)”.

Un punto importante está aquí. Aunque ambos servicios usan la misma base de datos, las renovaciones “en curso” deben decidirse por el servicio de Renovación. Puede basarse en el estado o la fecha de finalización del registro de renovación. Es hasta el Servicio de Renovación para decidir la lógica comercial para las renovaciones “en curso”. El Servicio de gestión de fondos no reclama propiedad sobre esa lógica.

  1. ¿Cuál es el principio / patrón SOA que explica el comportamiento anterior? (El uso del Servicio de Renovación para determinar las renovaciones “en curso” aunque existe el riesgo de que el Servicio de Renovación pueda cambiar la lógica por su propio interés). ¿Cuáles son las pautas sobre tales escenarios?

  2. ¿Tiene alguna sugerencia para cualquier artículo que se ocupe de tales decisiones de diseño?

  3. Dentro del Servicio de gestión de fondos, ¿quién debería ser responsable de validar que la lista de renovaciones devueltas es NULA? ¿Dónde debe ocurrir esta validación dentro del código del método de operación del servicio o dentro de FundBusinessLayer (a quién llama el servicio)?

Nota: Aquí, la SOA se implementará utilizando WCF y las clases de negocios se desarrollarán usando C #.

LEYENDO:

  1. SOA / WCF diseccionando los límites del sistema y del servicio

En este caso, no usaría los servicios existentes en el Servicio de renovación, como usted dice, podrían cambiar.

Sigo el principio de que en SOA los servicios deben tener un significado comercial.

Por lo tanto, crearía una nueva operación: IsContractRenewalInProgress . Esto elimina la necesidad de pensar en quién debería ser responsable de validar que la lista de renovaciones devuelta sea NULA. Lo más importante es que la lista es NULL significa que no hay renovaciones de contratos en curso.

El UpdateFundApprovalDate llamaría y verificaría el resultado de IsContractRenewalInProgress antes de realizar cambios.

IsContractRenewalInProgress debe estar en el Servicio de Renovación, ya que es el Servicio de Renovación el que posee los datos y la lógica comercial para saber cuándo está en curso la renovación de un contrato.

Cualquier procesamiento de información financiera va a girar en torno a una faceta clave: la gestión cuidadosa del estado.

Intente crear un modelo de estado para su sistema de contrato y documente cuidadosamente a qué estados se puede llegar desde un estado determinado, y qué procesamiento debe ocurrir para pasar de un estado válido a otro válido. Luego, asegúrese de que cualquier movimiento de un estado a otro ocurra en una transacción de manera que si no se logra el siguiente estado, el contrato vuelve a su estado anterior.

Puede encontrar que le será más fácil si granulariza sus estados para reflejar el procesamiento actual, es decir, en lugar de REVISADO, RENOVADO, APROBADO, RECHAZADO, FINANCIADO, también tienen estados que están configurados para indicar que un contrato está en un estado de flujo – es decir, se está revisando en este momento, se está financiando en este momento, etc. De esta forma, el sistema puede identificar los contratos que se están procesando activamente en este momento. También facilita la identificación de lo que estaba sucediendo si el entorno se bloqueara repentinamente sin una reversión exitosa.

Asegúrese de tener solo un servicio que actualice el estado de un contrato, y de que este servicio bloquee el contrato durante la actualización. Todos los otros procesos usarían este servicio para realizar los cambios de estado requeridos.

Por lo tanto, en su caso específico, el UpdateFundApprovalDate (Fondo de FundDTO) solo se ejecutará en contratos cuyo estado sea PENDING_FUNDING, y probablemente solo sea una parte del procesamiento total, sea cual sea el caso, cuando el proceso que ejecuta su updateFundApprovalDate (Fondo de FundDTO ) finaliza, el estado del contrato será FUNDIDO si fue exitoso, o si el bash de financiación falló, todos los cambios se habrán revertido, lo que dará como resultado el estado del contrato original de PENDING_FUNDING. Si el sistema falla, el estado del contrato podría dejarse en el estado de procesamiento actual, teniendo un estado similar a FINANCIACIÓN. FINANCIAR por sí mismo no sería un estado válido en su modelo de estado: es un estado interino. Todos los procesos solo comenzarán a procesar un contrato en un estado válido, nunca estados intermedios.

Para patrones que podrían usarse en esta situación, observe los patrones State Machine.