BRE Patterns III: Collaboration Cop, Part I

Dietrich Kappe, Tuesday, February 6, 2007 @ 12:28 am

The pattern I'm writing about today -- Collaboration Cop -- is much meatier than the two previous ones, in my opinion. This one is all about transplanting the implicit and explicit business rules of an OO system from its objects to an external BRE.

This is a somewhat involved pattern, and I'll provide some more examples and references in part II. Also in part II, I'll run down the differences between the rule classifications that come out this pattern and the ones you commonly see in works by Ross.

Pattern Name: Collaboration Cop

Synopsis
Extract the business logic that is in an OO domain model -- collaboration rules, property rules and controller logic -- and express it as a set of business rules. Activity in the system is triggered by the UI inserting events into the working memory and firing the rules. Objects can be persisted by something like and ORM framework.

Slightly longer version: if you strip away the user interface and the persistence mechamism, a typical OO application is designed around a domain model and controller or service classes that set object collaborations within the domain model in motion in response to external events. The methods of the controller/service classes often correspond to steps in a Use Case. Embedded in the various domain classes is logic about how object can be modified and accessed, what collaborations can be created or desolved, etc. With this pattern, you extract all the service/controller and validation and collaboration logic into business rules. You populate the working memory with the objects that comprise the context for a Use Case. Finally, in response to an external event, you inject an event object into the working memory and fire the rules that modify the state of the object model (and persist it).

Context
Take the somewhat simplified Use Case where a customer is trying to rent a tape (he's a sucker for punishment and doesn't like DVD's). In a OO system, we would try to create a collaboration as follows (yes, very simplified):

customer.addRental(new Rental(title.getTape()));

The customer object knows how many active rentals a customer has and knows hat he cannot have more than three. This attempted collaboration would throw an exception to indicate that it is not permitted.

In the Collaboration Cop version we would create an event and insert it into the working memory:

VideoStoreEvent event = new VideoStoreEvent();
event.type = VideoStoreEvent.RENT_TAPE;
event.value = "Gone With the Wind";


IF event.type == VideoStoreEvent.RENT_TAPE AND title.getTitle() == event.value AND title.isInStock()
AND customer.activeRentals() < 3
THEN
customer.addRental(new Rental(title.getTape()));
externalObjectSet.add(customer);
externalResponse.message = "Rented tape.";
externalResponse.success = true;
ELSE
externalResponse.message = "Unable to rent tape.";
externalResponse.success = false;

You can wrap a transaction around the sequence of event injections, then save (using an ORM) all of the modified objects in the externalObjectSet.

-----------

This pattern is complex and powerful, and it's implementation is very much dependent on the capabilities of the chosen BRE, how you choose to deal with concurrency, etc.. In part II, I'll also construct a simple example using JBoss Rules.

Technorati : bre, business rules, patterns

business rules

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment