I'm having a problem with the DRY principle (Don't Repeat Yourself) and minimizing dependencies that revolves around Rete rules engines.
Rules engines in large IT organizations tend to be Enterprise (note the capital "E" - that's serious business). All rules must be expressed once, nice and DRY, and centralized in an expensive rules engine. A group maintains the rules engine and are the keepers of the rules sets.
When that IT organization is part of an American insurance company, there tend to be lots of rules. There are rules that apply to all states and products, but each state tends to evolve its own laws for different products, so the rules need to reflect these quirks. The categories are many: actuarial, underwriting, even for ordering credit and motor vehicle reports from 3rd party bureaus.
The problem that I have from a design standpoint is that centralizing rules and processing is certainly nice and DRY, but there are costs:
- Additional network hops to access the centrally located rules service and return results;
- Additional complexity if the rules engine is exposed as a SOAP web service - consumers have to package up SOAP requests and OXM the response back to their own domain;
- Additional interfaces between the enterprise group that maintains the rules engine, the business that sets and maintains the rules, and the developers that consume them;
- Additional complexity - sometimes a data-driven solution might be enough.
- Additional dependencies - components who don't have control of their own rules have to worry about external dependencies on the rules engine for testing, deployment, releases, etc.
These problems crop up with lots of other Enterprise technologies (e.g., B2B gateways, ESBs, etc.)
The same Enterprise groups also tout SOA as a foundational principle. But my understanding of proper service design is that they should tile the business space an