I've inherited a somewhat complicated data-model in a SQL Database that I'll soon have an opportunity (read: nececssity) to overhaul. The data-model represents a Product catalog. So there's a table of products with lots and lots of other tables 1-3 generations deep containing category data, localized data, status etc. And there is an API above this data model that allows other systems to query it.

The crux of the issue is that there are numerous complex "Business Rules" in place that put define global filters what data the API returns. (e.g. exclude products from Manufacturer M in Category X, if it's after the 10th of the month, and the stock in Retailer Y is showing <= Z)

These rules were naively implemented in the database in a view. API -> EntityFramework Query -> View (Containing hacked in Where Clauses) -> Underlying Tables

The issues are obvious (maintenance, lack of testability, performance etc...)

This feels like a business rules problem where based some set of circumstances/conditions, we need to apply some set of global filters.

One thing I've been looking at is the Specification Pattern, where I could, based on some criteria (rules), inject a set of specifications that define these query filters.

This has the benefit of bringing both the rules & the filters up into code. It would also support a more plugin-based archiecture where Specification could be injected at runtime so we wouldn't necessarily have to go through a deployment cycle to add new rules.

Just wondering if there's something else I should consider, or if there are patterns/approaches or existing off that shelf software I should also have a look at.

  • Are your "business rules" only for access control and filtering ? – Christophe Dec 5 '17 at 12:58
  • Your proposed solution seems more complicated than it needs to be, and it's at odds with your goals. For example, you say that the Specification Pattern might solve your problem, stating that it has the benefit of bringing both the rules & the filters up into code, but then you propose a plugin architecture to fix the problem you just created, which is that the rules are now in code and therefore no longer configurable without a deploy. – Robert Harvey Dec 5 '17 at 17:27
  • Unfortunately there isn't enough information in your question about your specific problem to reasonably recommend a new solution. At a minimum, I would need to see a simple example of your existing solution. Have you considered simply using a better rules engine? – Robert Harvey Dec 5 '17 at 17:28
  • @Christophe Yes. these rules are all for applying either global filters or query filters based on some other criteria that a client/business person specifies. – Eoin Campbell Dec 6 '17 at 9:44
  • @Robert - I don't disagree with you. ultimately I don't want to redeploy when someone cooks up a new rule+filter. My first pass design for this is an filterspecification interface, that can be implemented. FilterSpecs could be written by a developer, and loaded dynamically into the app at run time. overcooked? maybe, but it satisfies both requirements of configurable at runtime and independently testable. It does seem though like something that's probably been done before/exists already, and it doesn't remove this isssue of this still being a Dev task. – Eoin Campbell Dec 6 '17 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.