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. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users