[rules-users] Abstraction between rules and data model?

[Péter Gergely, Horváth]

Hi Wolfgang,

Thank you for your input. You are right that some of the cases could simply
be covered by regexp-replace, but I'm afraid, not all of them. Interfaces
could also help, but we have a requirement that the business rules should
not be tightly coupled to the underlying persistence model. (I understand
that some might say this is not ideal, but that is our current situation)

I am wondering whether it is possible to hook into Drools engine and
intercept field value reference expression evaluations in run time (e.g if
"foo.bars" is used in an expression, we could return "foo.barList") ? By
injecting some custom code, we could make the necessary decisions and
extract the proper value from an object. Unfortunately these parts of
Drools are pretty much undocumented.

Regards,
Peter



2014-05-26 13:57 GMT+02:00 Wolfgang Laun <wolfgang.laun at gmail.com>:

> What you describe can be done with /bin/sed.
>
> Notice that the DSL processor doesn't require you to translate entire
> patterns; there is a mechanism for translating "keywords", which is
> just arbitrary tokens to whatever replacement text.
>
> If a "bar" must be translated to a "barList" in the context of a class
> "Foo" but not in any other context, a more sophisticated translation
> is required in any case (with /bin/sed still being sufficient if
> patterns aren't split across lines).
>
> Some say that good design makes use of Interfaces, which leaves room
> for actual implementations being changed as long as the interfaces are
> implemented. Here, note that rules can be written against interface
> types.
>
> -W
>
>
> On 26/05/2014, Péter Gergely, Horváth <h.peter at mailbox.hu> wrote:
> > Hi All,
> >
> > We are evaluating Drools 6 for our use case, and face challenges where we
> > would need some ideas from more experienced users of Drools.
> >
> > We have an application with a massive code base and a large number of
> model
> > (entity) classes. We are in the process of moving away from inherited
> > legacy technologies and refactoring the old code base. As a part of this
> > work we would like extract some of the hard-coded business logic to
> > external rules, that is why we are looking at Drools as a potential
> > solution.
> >
> > What we would like to have is some kind of abstraction or mapping between
> > actual entities and rules the business users can define so that they do
> not
> > have to know the _exact_ details of the data model (field names, precise
> > relations etc). This would be important for us so that we can refactor
> the
> > old model classes without affecting business rules; also it would make
> life
> > easier for the business users. While IDE support might make refactoring
> > easier, we definitely want to have a separation between rules and
> entities.
> >
> > Given our situation, writing and maintaining "stable" wrapper/adapter
> > classes for the sole purpose of rule processing is out of question. I
> have
> > checked the documentation of Drools DSL support and for me it seems to be
> > overkill for our use case: we do not really need a custom language, but
> > simply an abstraction between rules and the data model classes.
> >
> > What I could imagine is a piece of code, (a custom property resolver? -
> no
> > sure how it is called) which maps property expressions to actual
> properties
> > based on a custom annotation on the entity class or something like that,
> so
> > that a rule containing "Foo.bars" expression does not have to change even
> > if we decide to rename "Foo.bars" to "Foo.barList" in the model classes.
> > (This was just a simple example of a potential use cases)
> >
> > Could you please share your thoughts on this topic and point me into the
> > right direction?
> >
> > Thanks,
> > Peter
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140526/ffebc53a/attachment-0001.html