[rules-users] [rule engine advantage?]Logic and Data Separation - how to archieve the transparent domain/fact object insertion?

kapokfly ivan.jiang.ww at foxmail.com
Mon Nov 14 02:21:33 EST 2011


Logic and Data Separation
Your data is in your domain objects, the logic is in the rules. This is
fundamentally breaking the
OO coupling of data and logic, which can be an advantage or a disadvantage
depending on
your point of view. The upshot is that the logic can be much easier to
maintain as there are
changes in the future, as the logic is all laid out in rules. This can be
especially true if the logic
is cross-domain or multi-domain logic. Instead of the logic being spread
across many domain
objects or controllers, it can all be organized in one or more very distinct
rules files.

------------------------
The current practice we are following demonstrate a strong relationship
between fact objects and the rule files itself, the rule needs to understand
what fact object available in the working memory and the working memory may
also consider what kind of rules can be written against objects in memory
thus the application developers need insert/write rules carefully and better
to be done by 1 developer (or we can say, depends on how the rule is
written, it will impact what objects/how objects are being inserted into the
working memory). 

Can someone share their experiences how to make the knowledge session/fact
object maintenance work as transparent as possible? how to decouple the fact
object maintenance work from the rules? At which layer you usually insert
fact object to the work memory? 

Ivan   




-----
Ivan, your Panda, forever
--
View this message in context: http://drools.46999.n3.nabble.com/rule-engine-advantage-Logic-and-Data-Separation-how-to-archieve-the-transparent-domain-fact-object-i-tp3506131p3506131.html
Sent from the Drools: User forum mailing list archive at Nabble.com.



More information about the rules-users mailing list