It is very apparent that you read the book carefully and truly understand the vision I was trying to communicate. And I very much like the way you link the concepts in the book with actual technologies that are now emerging, such as the new breed of Java application servers. I wasn't actually prescient, of course -- I just saw greater potential in existing projects. It was a full ten years ago that I was arguing to my employers at Servio (now GemStone) Corp that what they called an object database was really a persistent application environment. It just [took] ten years for the market to catch up with the potential of this technology.

You said so many wonderful things about the book that I hardly know how to respond. The only critique I was able to find related to the use of rules, and your observation was quite valid -- the rules I describe are intentionally encaspulated and localized. I may have overstated the case for this, but I'm trying to offer some balance to the prevailing view that rules transcend objects and should therefore live outside of them. Personally, I think this is a big get-over-it; global rules will eventually go the way of global data and global functions, and for the same reasons -- global anythings are the enemy of scalability and adaptivity. *Every* rule has some context, and every rule should be encapsulated in the object that defines that context. How do we get rules to apply to multiple objects, then? Put them in the object that defines the context.

Example: a credit-risk rule that integrates information about an obligor, a property, interest rates, and other outstanding loans certainly should not be locked into any of those objects. But it shouldn't be a global rule that spans the organization either -- it's very specific to evaluating the risk associated with a particular outlay of cash, and shouldn't be mixed with rules about hiring policies, geographic ratings, and mortgage insurance. So what's the object that encapsulates it? That's a design decision, and it should be governed by the classic principles of coupling and cohesion. If the rule were only used to decide whether to grant a particular loan, I'd probably put it right in the loan object. That object already knows about the obligor, the property, etc., so it's a natural place to pull the information together to execute the rule. If the design needed to handle risk assessment in a larger context, then you'd probably want a dedicated risk object that lived solely to track various risk factors and integrate them using rules.

David A. Taylor, PhD
CEO, Enterprise Engines Inc.
San Mateo, CA 94404
dtaylor@engines.com