Re: [rules-users] Mapping complex objects info Guvnor compatible shim classes?

Your plan seems about right to me. When working in pure Drools, you don't always need to do this. However, when working in Guvnor, I have always found it necessary to create a simplified domain model for facts. In Guvnor, you can bind variables to fields and drill in, but it's fiddly. Guided rules are much more readable when they are dealing with matching bean-style facts with key attributes available through simple getX() accessor methods. And of course you definitely need the bean-style getX() methods. The other thing to think about, is that when working with Guvnor, you should be avoiding any dependencies on external classes from within your facts. Otherwise, you will need to put everything on your Guvnor web server's class path, which totally messes with your ability to upload fact model updates. Yet another reason to keep them simple. So given that you're going with that plan, here are my tips for the lazy (like me)... To help with simplifying your transformations, it may be worth looking at Dozer or similar: http://dozer.sourceforge.net/ Personally, because I have often found that I'm doing things like mapping multiple objects into a single fact, I tend to just do the mapping in straight Java code. It tends not to be too painful, as I rarely find the need for bi-directional mappings. I don't often need to get a fact back out of working memory. So although it feels a bit naughty, I often avoid the fact-to-domain-object transform. :) Think about what properties you really might want to write rules about. It's easy to spend a huge amount of time writing a huge fact model, and transforms for every single property of every class in your domain model. Truth is you probably won't write rules that look at all of it. So have a think about whether you do need to map everything or not. My tip here would be to follow a TDD approach. Look at what rules your users want to write. You should find that the rules mostly follow certain stereotypes, so create rule tests covering a representative selection of such stereotype (ensure coverage of all unique fact attributes which are examined). Create a fact model which can satisfy those tests. Create tests for transforming from your domain model to your fact model. Create transforms to that fact model. Assuming you have a reasonably iterative environment, you can add transforms for additional attributes when users have tried out the application and come up with new rule stereotypes they would like to work with. As an alternative (or to complement the above), take a look at DSLs. Each DSL phrase becomes available in your guided editor, so you can have simple rule phrases which the users can understand, but underneath, you can have code which is drilling into nested objects. I do hope that's helpful… :) Steve On 10 Aug 2013, at 00:47, Mark Bennett <mark.bennett(a)lucidworks.com&gt; wrote: