¿Cómo equilibrar principio DRY con la minimización dependencias?

Question

Estoy teniendo un problema con el principio DRY (Do not Repeat Yourself) y minimizando las dependencias que gira en torno a los motores de reglas Rete.

Los motores de reglas en las grandes organizaciones de TI tienden a ser Empresa (tenga en cuenta la capital "E" - que es un asunto serio). Todas las reglas se deben expresar una vez, agradable y seco, y centralizada en un motor de reglas caro. Un grupo mantiene el motor de reglas y son los guardianes de los conjuntos de reglas.

Cuando esa organización de TI es parte de una compañía de seguros estadounidense, tiende a haber un montón de reglas. Hay reglas que se aplican a todos los estados y de los productos, pero cada estado tiende a evolucionar sus propias leyes para diferentes productos, por lo que las reglas deben reflejar estas peculiaridades. Las categorías son muchas: actuarial, suscripción, incluso para pedir informes de crédito de vehículos de motor y de las oficinas de tercera parte.

El problema que tengo desde el punto de vista del diseño es que las reglas de procesamiento y de centralización es ciertamente agradable y seco, pero hay costos:

1. red adicional saltos para acceder al servicio de reglas situado en el centro y los resultados de retorno;
2. complejidad adicional si el motor de reglas se expone como un servicio web SOAP - los consumidores tienen que empaquetar las peticiones SOAP y OXM la respuesta de vuelta a su propio dominio;
3. Otras interfaces entre el grupo empresarial que mantiene el motor de reglas, el negocio que establece y mantiene las reglas, y los desarrolladores que los consumen;
4. complejidad adicional -. A veces una solución basada en datos podría ser suficiente
5. dependencias adicionales -. Componentes que no tienen el control de sus propias reglas tienen que preocuparse acerca de las dependencias externas en el motor de reglas para las pruebas, despliegue, comunicados, etc.

Estos problemas surgen con una gran cantidad de otras tecnologías de la empresa (por ejemplo, pasarelas B2B, ESB, etc.)

Los mismos grupos empresariales también tout SOA como un principio fundamental. Pero mi comprensión del diseño de un servicio adecuado es que deben baldosas del espacio de negocios y idempotente, independiente y aislada. ¿Cómo puede un servicio independiente y aislada si sus normas se mantienen en otro lugar?

Me gustaría errar por el lado de la simplicidad, argumentando que la eliminación de las dependencias debe prevalecer sobre la centralización si se pueden mostrar las reglas a aplicar sólo en circunstancias aisladas. No estoy seguro de la discusión va a ganar el día.

Así que mis preguntas son:

1. ¿Dónde se cae en la centralización o argumento de la independencia?
2. ¿Cuál es su experiencia con las herramientas de la empresa, como los motores de reglas?
3. ¿Cómo puedo hacer que el argumento más fuerte para el aislamiento?
4. Si mi punto de vista no es correcto, lo que le hace argumento a favor de la centralización?

Answer 1

A la larga, fácil mantenimiento de todo el asunto sería un requisito absoluto.

Así que seca debe ser honrado a toda costa, incluso si eso implica una pérdida de rendimiento aquí y allá, algunos problemas de configuración adicionales y otros problemas "menores".

También "independiente" es diferente de "autónomos".

De lo contrario imaginar la situación en la que tenga que cambiar algo y tiene que ponerse en contacto con una gran cantidad de diferentes partes de forzarlos a actualizar. Con SECO también resolver el problema de tener que ejecutan versiones incompatibles en el mismo momento por un breve período de tiempo.

Entonces

1. La centralización> Indepenence (al menos en el sistema que describes)
2. Un único punto de la verdad para los motores de reglas (todos en la misma página)
3. Recuérdeles el costo de mantenimiento como los años pasan
4. Encuentro su punto de vista correcto.

Answer 2

Su pregunta es muy específica para empresas, y yo estoy más en cosas de escritorio, así que espero que esta respuesta no es demasiado general. Me gustó el concepto de no repita usted mismo, hasta que me di cuenta de lo que estaba siendo codificado y osificado. Me gustó porque estaba de acuerdo conmigo (la!) Y mis propias ideas sobre cómo hacer que el código sea más fácil de mantener y menos propenso a errores. Básicamente, veo una mayor facilidad de mantenimiento, requiere más de una curva de aprendizaje por parte del mantenedor. Creo que no hay una manera fácil de evitar eso. Aquí está un ejemplo de cómo aumentar la capacidad de mantenimiento de un buen factor, pero no sin una curva de aprendizaje.