12

I just started working for a government agency and I have come across an interesting problem: business rules depend on legislature and as such they have to respect the exact time periods that legislature has been active.

To give you an example, if a subject has applied for a subsidy on a certain date, than he has to be evaluated according to criteria that vas valid on that given date. That same subsidy, for someone that applied on some later date has different criteria. I was wondering if there is a known pattern to deal with these time-dependent rules in orderly fashion. At the moment, the code is sprinkled with expressions akin to:

if application.date >”July 17th, 2008”

What is the best way to manage this problem?

Dan
  • 11,077
  • 20
  • 84
  • 119

4 Answers4

7

This looks like a case for Chain of Responsibility. You would have handlers for each legislature. You pass the application to the most recent handler first. If it is too old, it passes it down to the handler for the previous legislature.

Björn Pollex
  • 75,346
  • 28
  • 201
  • 283
  • this looks like right approach, since you can add new handlers withouth modifying the old ones. – Dan Jul 01 '11 at 15:38
5

You can use a few patterns. For example using the temporal property pattern you can create on object which contains business rules which are active at a certain point in time. Also, using the specification pattern you can create business rules which are effective based on a certain date. You can associate an effective date range with each policy so that the decision of whether a given policy applies can be made. The book Analysis Patterns contains many patterns that could be applicable in your scenario.

EDIT: I meant to link to the temporal object pattern instead of temporal property. This may shed some light on implementing the database mapping.

eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • temporal property pattern is usefull for having time-dependent data, which is also the case in problem domain I am looking into. – Dan Jun 30 '11 at 21:29
  • @Dan. I like this approach too; solve the problem from a domain perspective first. Once you do it should be relatively trivial to have a validator enforce this. – Berryl Jul 01 '11 at 05:16
  • Good to see Analysis Patterns get some mention - wish that Fowler would publish a 2nd edition of that along with more examples of usage. Cheers – Berryl Jul 01 '11 at 05:19
  • I guess "temporal property" needs some tweaking to get it working with ORMs, possibly calculated field? – Dan Jul 01 '11 at 15:36
  • No, a temporal property really asks for a OODB. RDBMSs are terrible with them. – Stephan Eggermont Jul 08 '11 at 21:36
1

If the rules are complex you may need a (business) rules engine. I don't know what implementations exist for your platform, but for Java the typical choice is Drools and its Expert subproject. It defines domain-specific language for defining rules. Note that it might have an interface for non-java users.

Otherwise you may try something like the Strategy pattern - you have a list of strategies with two methods appliesTo(date) and handle(data). You iterate the list and if a strategy is applicable to a date - let it handle the data.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
0

At the architecture level, there are two approaches to solve this problem.

The first is to ETL the data to your Warehouse before the business logic is applied against the data. I prefer this approach.

Sometimes though, it's not possible to do this--i.e., the business logic is applied against the data before it is written to the OLTP (the source used to populate the Data Warehouse) so you have no choice. In this instance, this problem is usually referred to as a rapidly changing dimension problem. (My assumption here is that the data referred to in your question is stored in a Dimension Table rather than a Fact Table).

There is a vast body of commentary on this subject available on the Web. Among these sources, i recommend any of the articles (free) or books (not free) by Ralph Kimball.

The best way to reconcile a rapidly changing dimension is almost certainly fact specific; still, perhaps the most common technique is to c*reate a new dimension table* that stores the data applied against the new business logic. In other words, you would have in your DW schema a separate dimension table for for each business rule.

doug
  • 69,080
  • 24
  • 165
  • 199