oop - strategy - Reglas comerciales que son válidas para un lapso de tiempo específico: cómo administrarlas de manera ordenada
strategy pattern (4)
Empecé a trabajar para una agencia gubernamental y me encontré con un problema interesante: las reglas comerciales dependen de la legislatura y, como tales, deben respetar los períodos de tiempo exactos que la legislatura ha estado activa.
Para dar un ejemplo, si un sujeto ha solicitado un subsidio en una fecha determinada, entonces debe ser evaluado de acuerdo con los criterios que eran válidos en esa fecha determinada. Ese mismo subsidio, para alguien que solicitó una fecha posterior tiene diferentes criterios. Me preguntaba si existe un patrón conocido para tratar estas reglas dependientes del tiempo de manera ordenada. Por el momento, el código está salpicado con expresiones similares a:
if application.date >”July 17th, 2008”
¿Cuál es la mejor manera de manejar este problema?
En el nivel de la arquitectura, hay dos enfoques para resolver este problema.
El primero es ETL los datos a su Almacén antes de que la lógica de negocios se aplique contra los datos. Yo prefiero este enfoque.
A veces, sin embargo, no es posible hacer esto, es decir, la lógica de negocios se aplica a los datos antes de que se escriban en el OLTP (la fuente utilizada para llenar el Almacén de datos), por lo que no tiene otra opción. En este caso, este problema generalmente se conoce como un problema de dimensión que cambia rápidamente . (Mi suposición aquí es que los datos a los que se hace referencia en su pregunta se almacenan en una Tabla de dimensiones en lugar de en una Tabla de hechos).
Hay una gran cantidad de comentarios sobre este tema disponibles en la Web. Entre estas fuentes, recomiendo cualquiera de los artículos (gratis) o libros (no gratis) por Ralph Kimball .
La mejor manera de reconciliar una dimensión que cambia rápidamente es casi con seguridad específica de los hechos; aún así, tal vez la técnica más común es crear una nueva tabla de dimensiones * que almacene los datos aplicados contra la nueva lógica comercial. En otras palabras, tendría en su esquema de DW una tabla de dimensiones separada para cada regla de negocio.
Esto parece un caso de Cadena de responsabilidad . Tendría manipuladores para cada legislatura. Primero pasa la aplicación al controlador más reciente. Si es demasiado viejo, se lo pasa al manejador de la legislatura anterior.
Puedes usar algunos patrones. Por ejemplo, utilizando el patrón de propiedad temporal que puede crear en un objeto que contiene reglas comerciales que están activas en un momento determinado. Además, utilizando el patrón de especificación , puede crear reglas comerciales que sean efectivas en función de una fecha determinada. Puede asociar un intervalo de fechas efectivo con cada política para que se pueda tomar la decisión de si se aplica una política determinada. El libro Patrones de análisis contiene muchos patrones que podrían ser aplicables en su escenario.
EDITAR: Quise vincular el patrón de objeto temporal en lugar de la propiedad temporal. Esto puede arrojar algo de luz sobre la implementación del mapeo de la base de datos.
Si las reglas son complejas, es posible que necesite un motor de reglas (comercial) . No sé qué implementaciones existen para su plataforma, pero para Java la elección típica es Drools y su subproyecto experto . Define un lenguaje específico de dominio para definir reglas. Tenga en cuenta que podría tener una interfaz para usuarios que no sean de Java.
De lo contrario, puede intentar algo como el patrón de estrategia : tiene una lista de estrategias con dos métodos appliesTo(date) y handle(data) . Usted itera la lista y si una estrategia es aplicable a una fecha, deje que maneje los datos.