Discussion:
rules engines
christoferjennings
2004-12-18 22:58:20 UTC
Permalink
Has anyone in this group used rules engines with DDD?

I'm just starting work on a custom J2EE stock trading application where employees can
purchase and sell stocks of their company periodically. At first glance it seem slike it
should be simple but I've been told that there is a lot of complexity driven by business
rules. The rules have evolved over years at the company, and I don't understand them yet.

On the project, there seems to be a feeling (or hope anyway) that the Weblogic Integration
Platform (WLI) can be used to capture business rules in a visual way that business analists
can modify them. Has anyone in this group used WLI or other rules engines as part of a
domain driven design effort? or have any suggestions on good books (hopefully thin ;-) to
learn how to work effectively with rules engines?

Thanks in advance.
,boz





------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Zhiyi Zhang
2004-12-19 06:49:06 UTC
Permalink
I don't have any experience with rules engines, but for one thing, I'd
make domain business logic platform-independent as much as possible.

I understand that some platforms may help you develop your business
domain, however, all platforms have limitations and restictions. You
need to understand whether the platform meets your requirements.
Secondly, you need to maintain a good guidance on how to use the
platform. I've often seen that platform adds additional complexity
which makes business logic hard to understand, to maintain, and to
enhance, as software life-cyle goes on. Lastly, but not least
importantly, it's a much less pain to replace one platform with
another one if your domain business logic is platform-independent.

My $.02.

- z


On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application where employees can
purchase and sell stocks of their company periodically. At first glance it seem slike it
should be simple but I've been told that there is a lot of complexity driven by business
rules. The rules have evolved over years at the company, and I don't understand them yet.
On the project, there seems to be a feeling (or hope anyway) that the Weblogic Integration
Platform (WLI) can be used to capture business rules in a visual way that business analists
can modify them. Has anyone in this group used WLI or other rules engines as part of a
domain driven design effort? or have any suggestions on good books (hopefully thin ;-) to
learn how to work effectively with rules engines?
Thanks in advance.
,boz
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
christoferjennings
2004-12-19 18:33:04 UTC
Permalink
Good point Zhiyi. I agree completely that the business logic should be platform
independent. I'm pushing for us to use a DDD approach with business logic in plain old
java objects (POJOs) to keep from getting to tied to WLI. Hopefully we can find a good
balance between short-term productivity and maintainability.

Since my first post I've done a little digging into rules engines. In the java world, there are
some basic standards (JSR 94) and there are open-source and proprietary engines. It turns
out the WLI does not have a real engine but promotes using ILOG's JRules. Of course this
gets us back to the platform question. It seems tome that if you use Jess or DROOLS or
JRules etc. then the rules will be pretty much tied to the engine. We'll have to consider the
trade-offs there.

Another thing I noticed is that rules seem kind of like the Specification pattern in DDD.
May it's better said that Specification might be a way to implement a rules engine. I don't
want to implement a rules engine if I don't have to, so now I'm wondering if a rules engine
could be used like Specification. That is, in a domain object that needs rules, maybe the
rules engine (or a set of rules) could be injected. Then the domain objects behavior would
be governed by the rules.... And that's as far as my brain has got so far :-)

The little I've read about rules make me think the paradigm is the opposite: Instead of
domain objects having rules, rules are supposed to have domain objects. Can the two
ideas work together? Or does declarative programming force a different approach to
domains that is not based on rich object models but on rich rules models?

Hmmm.
,boz
Post by Zhiyi Zhang
I don't have any experience with rules engines, but for one thing, I'd
make domain business logic platform-independent as much as possible.
I understand that some platforms may help you develop your business
domain, however, all platforms have limitations and restictions. You
need to understand whether the platform meets your requirements.
Secondly, you need to maintain a good guidance on how to use the
platform. I've often seen that platform adds additional complexity
which makes business logic hard to understand, to maintain, and to
enhance, as software life-cyle goes on. Lastly, but not least
importantly, it's a much less pain to replace one platform with
another one if your domain business logic is platform-independent.
My $.02.
- z
On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application where employees can
purchase and sell stocks of their company periodically. At first glance it seem slike it
should be simple but I've been told that there is a lot of complexity driven by business
rules. The rules have evolved over years at the company, and I don't understand them yet.
On the project, there seems to be a feeling (or hope anyway) that the Weblogic Integration
Platform (WLI) can be used to capture business rules in a visual way that business analists
can modify them. Has anyone in this group used WLI or other rules engines as part of a
domain driven design effort? or have any suggestions on good books (hopefully thin ;-) to
learn how to work effectively with rules engines?
Thanks in advance.
,boz
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
christoferjennings
2004-12-19 21:13:41 UTC
Permalink
Steve,

Thanks for pointing out the pages in DDD. I don't have the book with me. :-(

Have you seen this article?
http://www.theserverside.com/articles/article.tss?l=RuleBasedMDB

The author shows a way to implement rules in plain java and describes how it might work
with message driven beans. I just don't know what to make of it yet....

For my project, I think we could get the funding for JRules (there's a real push to "leverage
BEA" that would support it and a desire to not use open source (that I don't agree with))
but like you said we've got to come at it skeptically, with an open mind. I don't know if we
have the time for the learning curve of JRules. I also don't know if we have the time to
develop a Specifications-like approach. (sigh) Thank you for bringing up the Ubiquitous
Language. It does seem like that will be the key. Fortunately I think there is a pretty well
developed language in the stocks department. Unfortunately it is not well documented and
we software designers haven't learned it yet.

On a nuts and bolts level, I just don't want to promote a design or tool that pushes us
away from a rich object model for the domain. (That's my personal preference, that the
richest reflection of the domain be in OO.) On the other hand, I want to promote the best
solution I can think of. This discussion is helping a lot to figure out if rules engines are in
it.

Could you give more detail about getting the right domain object into the rules context?
This may be a dumb question, but how did you come to see it as the interesting bit?

Thanks!,
boz
I'm interested in this topic as well, as we're looking into using a rules engine on my new
project. Eric discusses integrating rules engines with a domain model on pp. 120-122 of
1. Be skeptical. On my project, we'll need to make sure that we aren't just introducing a
rules engine for the coolness factor, or because we never really applied OO. Eric explains
how to represent less obvious kinds of objects in chapter 9, for example specifications, in
standard OO languages. And there's benefits to sticking with one paradigm - no
impedence mismatches.
Nevertheless, I have worked on similar projects at my company where a rules engine
seemed appealing; we just never got around to investigating. So I'm glad this team is
looking into it. I hope to learn something.
2. Lean on the ubiquitous language. Using the same terms should help unify and
connect the domain model with the rules.
My thought is that rules are one way of implementing policies. I think your example of
using a rules engine as a way to implement a policy is very good. I think you nailed the
main issue with your last point - with a domain model, domain objects have rules; with a
rules engine, rules have domain objects. Hopefully using the ubiquitous language will
help bridge the gap. We're looking into Drools, which allows for a fairly tight integration
between Java code and rules. Rules can refer to Java objects, and methods or properties
on those objects. But of course you lose some portability.
Our tentative plan is to do just as you described. We'll treat create Java interfaces for
our policy objects, implement the policies via the rules engine. So the rest of domain
model doesn't know or depend on the rules engine directly. The interesting bit is how to
pass the right domain object to the rules engine context, for it to operate on. Any
thoughts there?
Steve
-----Original Message-----
Sent: Sun 12/19/2004 12:33 PM
Subject: [domaindrivendesign] Re: rules engines
Good point Zhiyi. I agree completely that the business logic should be platform
independent. I'm pushing for us to use a DDD approach with business logic in plain old
java objects (POJOs) to keep from getting to tied to WLI. Hopefully we can find a good
balance between short-term productivity and maintainability.
Since my first post I've done a little digging into rules engines. In the java world, there
are
some basic standards (JSR 94) and there are open-source and proprietary engines. It
turns
out the WLI does not have a real engine but promotes using ILOG's JRules. Of course this
gets us back to the platform question. It seems tome that if you use Jess or DROOLS or
JRules etc. then the rules will be pretty much tied to the engine. We'll have to consider
the
trade-offs there.
Another thing I noticed is that rules seem kind of like the Specification pattern in DDD.
May it's better said that Specification might be a way to implement a rules engine. I
don't
want to implement a rules engine if I don't have to, so now I'm wondering if a rules
engine
could be used like Specification. That is, in a domain object that needs rules, maybe the
rules engine (or a set of rules) could be injected. Then the domain objects behavior
would
be governed by the rules.... And that's as far as my brain has got so far :-)
The little I've read about rules make me think the paradigm is the opposite: Instead of
domain objects having rules, rules are supposed to have domain objects. Can the two
ideas work together? Or does declarative programming force a different approach to
domains that is not based on rich object models but on rich rules models?
Hmmm.
,boz
Post by Zhiyi Zhang
I don't have any experience with rules engines, but for one thing, I'd
make domain business logic platform-independent as much as possible.
I understand that some platforms may help you develop your business
domain, however, all platforms have limitations and restictions. You
need to understand whether the platform meets your requirements.
Secondly, you need to maintain a good guidance on how to use the
platform. I've often seen that platform adds additional complexity
which makes business logic hard to understand, to maintain, and to
enhance, as software life-cyle goes on. Lastly, but not least
importantly, it's a much less pain to replace one platform with
another one if your domain business logic is platform-independent.
My $.02.
- z
On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application where employees
can
Post by Zhiyi Zhang
Post by christoferjennings
purchase and sell stocks of their company periodically. At first glance it seem slike
it
Post by Zhiyi Zhang
Post by christoferjennings
should be simple but I've been told that there is a lot of complexity driven by
business
Post by Zhiyi Zhang
Post by christoferjennings
rules. The rules have evolved over years at the company, and I don't understand
them
yet.
Post by Zhiyi Zhang
Post by christoferjennings
On the project, there seems to be a feeling (or hope anyway) that the Weblogic
Integration
Post by Zhiyi Zhang
Post by christoferjennings
Platform (WLI) can be used to capture business rules in a visual way that business
analists
Post by Zhiyi Zhang
Post by christoferjennings
can modify them. Has anyone in this group used WLI or other rules engines as part
of
a
Post by Zhiyi Zhang
Post by christoferjennings
domain driven design effort? or have any suggestions on good books (hopefully
thin
;-) to
Post by Zhiyi Zhang
Post by christoferjennings
learn how to work effectively with rules engines?
Thanks in advance.
,boz
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Molitor, Stephen L
2004-12-19 19:34:30 UTC
Permalink
I'm interested in this topic as well, as we're looking into using a rules engine on my new project. Eric discusses integrating rules engines with a domain model on pp. 120-122 of the book. Two point he makes stand out:

1. Be skeptical. On my project, we'll need to make sure that we aren't just introducing a rules engine for the coolness factor, or because we never really applied OO. Eric explains how to represent less obvious kinds of objects in chapter 9, for example specifications, in standard OO languages. And there's benefits to sticking with one paradigm - no impedence mismatches.

Nevertheless, I have worked on similar projects at my company where a rules engine seemed appealing; we just never got around to investigating. So I'm glad this team is looking into it. I hope to learn something.

2. Lean on the ubiquitous language. Using the same terms should help unify and connect the domain model with the rules.

My thought is that rules are one way of implementing policies. I think your example of using a rules engine as a way to implement a policy is very good. I think you nailed the main issue with your last point - with a domain model, domain objects have rules; with a rules engine, rules have domain objects. Hopefully using the ubiquitous language will help bridge the gap. We're looking into Drools, which allows for a fairly tight integration between Java code and rules. Rules can refer to Java objects, and methods or properties on those objects. But of course you lose some portability.

Our tentative plan is to do just as you described. We'll treat create Java interfaces for our policy objects, implement the policies via the rules engine. So the rest of domain model doesn't know or depend on the rules engine directly. The interesting bit is how to pass the right domain object to the rules engine context, for it to operate on. Any thoughts there?

Steve



-----Original Message-----
From: christoferjennings [mailto:***@yahoo.com]
Sent: Sun 12/19/2004 12:33 PM
To: ***@yahoogroups.com
Cc:
Subject: [domaindrivendesign] Re: rules engines



Good point Zhiyi. I agree completely that the business logic should be platform
independent. I'm pushing for us to use a DDD approach with business logic in plain old
java objects (POJOs) to keep from getting to tied to WLI. Hopefully we can find a good
balance between short-term productivity and maintainability.

Since my first post I've done a little digging into rules engines. In the java world, there are
some basic standards (JSR 94) and there are open-source and proprietary engines. It turns
out the WLI does not have a real engine but promotes using ILOG's JRules. Of course this
gets us back to the platform question. It seems tome that if you use Jess or DROOLS or
JRules etc. then the rules will be pretty much tied to the engine. We'll have to consider the
trade-offs there.

Another thing I noticed is that rules seem kind of like the Specification pattern in DDD.
May it's better said that Specification might be a way to implement a rules engine. I don't
want to implement a rules engine if I don't have to, so now I'm wondering if a rules engine
could be used like Specification. That is, in a domain object that needs rules, maybe the
rules engine (or a set of rules) could be injected. Then the domain objects behavior would
be governed by the rules.... And that's as far as my brain has got so far :-)

The little I've read about rules make me think the paradigm is the opposite: Instead of
domain objects having rules, rules are supposed to have domain objects. Can the two
ideas work together? Or does declarative programming force a different approach to
domains that is not based on rich object models but on rich rules models?

Hmmm.
,boz
Post by Zhiyi Zhang
I don't have any experience with rules engines, but for one thing, I'd
make domain business logic platform-independent as much as possible.
I understand that some platforms may help you develop your business
domain, however, all platforms have limitations and restictions. You
need to understand whether the platform meets your requirements.
Secondly, you need to maintain a good guidance on how to use the
platform. I've often seen that platform adds additional complexity
which makes business logic hard to understand, to maintain, and to
enhance, as software life-cyle goes on. Lastly, but not least
importantly, it's a much less pain to replace one platform with
another one if your domain business logic is platform-independent.
My $.02.
- z
On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application where employees
can
Post by Zhiyi Zhang
Post by christoferjennings
purchase and sell stocks of their company periodically. At first glance it seem slike it
should be simple but I've been told that there is a lot of complexity driven by business
rules. The rules have evolved over years at the company, and I don't understand them
yet.
Post by Zhiyi Zhang
Post by christoferjennings
On the project, there seems to be a feeling (or hope anyway) that the Weblogic
Integration
Post by Zhiyi Zhang
Post by christoferjennings
Platform (WLI) can be used to capture business rules in a visual way that business
analists
Post by Zhiyi Zhang
Post by christoferjennings
can modify them. Has anyone in this group used WLI or other rules engines as part of
a
Post by Zhiyi Zhang
Post by christoferjennings
domain driven design effort? or have any suggestions on good books (hopefully thin
;-) to
Post by Zhiyi Zhang
Post by christoferjennings
learn how to work effectively with rules engines?
Thanks in advance.
,boz
Yahoo! Groups Links











------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Molitor, Stephen L
2004-12-20 15:20:07 UTC
Permalink
Yeah, I skimmed that article a while back. I didn't quite get the
point. I understand how plain Java objects can implement business
rules. And I understand how, if you need to trigger some processing
asynchronously, you can use MDB's. And of course the logic in the MDB's
could be business rules. Didn't seem that earth shattering though. And
in general, I wouldn't want to incur the expense of a distributed
business rules engine (data transfer objects, the whole nine yards)
except in cases where I really needed to.
Post by christoferjennings
Could you give more detail about getting the right domain object into
the rules context?
Post by christoferjennings
This may be a dumb question, but how did you come to see it as the
interesting bit?

Let's say I have an order class, that delegates to a policy, or
specification, for its validation rules:

class Order {
private OrderValidator orderValidator;

public void validate() throws ValidationException {
orderValidator.validate(this);
}

public double total() {...}

public String placedBy() {...}
}

I want to implement OrderValidator via a rule. The rule will depend on
the order. In Drools it might look something like this:

<rule name="OrderValidator">
<parameter identifier="order">
<java:class>com.acme.Order</java:class>
</parameter>
<java:condition>order.total() > 1.00 &&
order.placedBy().equals("Fran")</java:condition>
<java:consequence>throw new ValidationException("Credit checked
failed");</java:consequence>
</rule>

To run that rule, I might have to do something like this:

class DroolsOrderValidator implements OrderValidator {

public void validate(Order order) {
WorkingMemory workingMemory = getWorkingMemoryFromDrools(...);
workingMemory.assertObject(order); // make the rules engine aware of
the order
workingMeomry.fireAllRules();
}
}

I guess I'd use dependency injection to plug the DroolsOrderValidator
into the order. Come to think of it, I guess it's not that bad after
all!

We're using Hibernate, which provides callback methods for interesting
events like inserting, updating, or deleting entities. So I guess we
could provide a hook that would assert all changed entities into the
Drools working memory, fire all the rules, and roll back the transaction
if there were any errors. The rules could be validation rules, or
integration type rules -- i.e. the consequences might be to send an
email whenever a particular entity is updated; send a message to another
system; sync some data with a legacy system, etc. Drools allows you to
invoke normal Java code from a rule, so the integration logic wouldn't
have to be coded in the rule, just the conditions as to when to fire off
the integration code.

Steve

-----Original Message-----
From: christoferjennings [mailto:***@yahoo.com]
Sent: Sunday, December 19, 2004 3:14 PM
To: ***@yahoogroups.com
Subject: [domaindrivendesign] Re: rules engines



Steve,

Thanks for pointing out the pages in DDD. I don't have the book with me.
:-(

Have you seen this article?
http://www.theserverside.com/articles/article.tss?l=RuleBasedMDB

The author shows a way to implement rules in plain java and describes
how it might work with message driven beans. I just don't know what to
make of it yet....

For my project, I think we could get the funding for JRules (there's a
real push to "leverage BEA" that would support it and a desire to not
use open source (that I don't agree with)) but like you said we've got
to come at it skeptically, with an open mind. I don't know if we have
the time for the learning curve of JRules. I also don't know if we have
the time to develop a Specifications-like approach. (sigh) Thank you for
bringing up the Ubiquitous Language. It does seem like that will be the
key. Fortunately I think there is a pretty well developed language in
the stocks department. Unfortunately it is not well documented and we
software designers haven't learned it yet.

On a nuts and bolts level, I just don't want to promote a design or tool
that pushes us away from a rich object model for the domain. (That's my
personal preference, that the richest reflection of the domain be in
OO.) On the other hand, I want to promote the best solution I can think
of. This discussion is helping a lot to figure out if rules engines are
in it.

Could you give more detail about getting the right domain object into
the rules context?
This may be a dumb question, but how did you come to see it as the
interesting bit?

Thanks!,
boz
Post by christoferjennings
I'm interested in this topic as well, as we're looking into using a
rules engine on my new
project. Eric discusses integrating rules engines with a domain model
Post by christoferjennings
1. Be skeptical. On my project, we'll need to make sure that we
aren't just introducing a
rules engine for the coolness factor, or because we never really applied
OO. Eric explains how to represent less obvious kinds of objects in
chapter 9, for example specifications, in standard OO languages. And
there's benefits to sticking with one paradigm - no impedence
mismatches.
Post by christoferjennings
Nevertheless, I have worked on similar projects at my company where a
rules engine
seemed appealing; we just never got around to investigating. So I'm
glad this team is looking into it. I hope to learn something.
Post by christoferjennings
2. Lean on the ubiquitous language. Using the same terms should help
unify and
connect the domain model with the rules.
Post by christoferjennings
My thought is that rules are one way of implementing policies. I
think your example of
using a rules engine as a way to implement a policy is very good. I
think you nailed the main issue with your last point - with a domain
model, domain objects have rules; with a rules engine, rules have domain
objects. Hopefully using the ubiquitous language will help bridge the
gap. We're looking into Drools, which allows for a fairly tight
integration between Java code and rules. Rules can refer to Java
objects, and methods or properties on those objects. But of course you
lose some portability.
Post by christoferjennings
Our tentative plan is to do just as you described. We'll treat create
Java interfaces for
our policy objects, implement the policies via the rules engine. So the
rest of domain model doesn't know or depend on the rules engine
directly. The interesting bit is how to
pass the right domain object to the rules engine context, for it to
operate on. Any
thoughts there?
Post by christoferjennings
Steve
-----Original Message-----
Sent: Sun 12/19/2004 12:33 PM
Subject: [domaindrivendesign] Re: rules engines
Good point Zhiyi. I agree completely that the business logic should be
platform independent. I'm pushing for us to use a DDD approach with
business logic in plain old java objects (POJOs) to keep from getting
to tied to WLI. Hopefully we can find a good balance between
short-term productivity and maintainability.
Post by christoferjennings
Since my first post I've done a little digging into rules engines. In
the java world, there
are
Post by christoferjennings
some basic standards (JSR 94) and there are open-source and
proprietary engines. It
turns
Post by christoferjennings
out the WLI does not have a real engine but promotes using ILOG's
JRules. Of course this gets us back to the platform question. It seems
tome that if you use Jess or DROOLS or JRules etc. then the rules will
be pretty much tied to the engine. We'll have to consider
the
Post by christoferjennings
trade-offs there.
Another thing I noticed is that rules seem kind of like the
Specification pattern in DDD.
Post by christoferjennings
May it's better said that Specification might be a way to implement a
rules engine. I
don't
Post by christoferjennings
want to implement a rules engine if I don't have to, so now I'm
wondering if a rules
engine
Post by christoferjennings
could be used like Specification. That is, in a domain object that
needs rules, maybe the rules engine (or a set of rules) could be
injected. Then the domain objects behavior
would
Post by christoferjennings
be governed by the rules.... And that's as far as my brain has got so
far :-)
The little I've read about rules make me think the paradigm is the
opposite: Instead of domain objects having rules, rules are supposed
to have domain objects. Can the two ideas work together? Or does
declarative programming force a different approach to domains that is
not based on rich object models but on rich rules models?
Post by christoferjennings
Hmmm.
,boz
Post by Zhiyi Zhang
I don't have any experience with rules engines, but for one thing,
I'd make domain business logic platform-independent as much as
possible.
Post by christoferjennings
Post by Zhiyi Zhang
I understand that some platforms may help you develop your business
domain, however, all platforms have limitations and restictions. You
need to understand whether the platform meets your requirements.
Secondly, you need to maintain a good guidance on how to use the
platform. I've often seen that platform adds additional complexity
which makes business logic hard to understand, to maintain, and to
enhance, as software life-cyle goes on. Lastly, but not least
importantly, it's a much less pain to replace one platform with
another one if your domain business logic is platform-independent.
My $.02.
- z
On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application
where employees
can
Post by Zhiyi Zhang
Post by christoferjennings
purchase and sell stocks of their company periodically. At first
glance it seem slike
it
Post by christoferjennings
Post by Zhiyi Zhang
Post by christoferjennings
should be simple but I've been told that there is a lot of
complexity driven by
business
Post by christoferjennings
Post by Zhiyi Zhang
Post by christoferjennings
rules. The rules have evolved over years at the company, and I
don't understand
them
Post by christoferjennings
yet.
Post by Zhiyi Zhang
Post by christoferjennings
On the project, there seems to be a feeling (or hope anyway) that
the Weblogic
Integration
Post by Zhiyi Zhang
Post by christoferjennings
Platform (WLI) can be used to capture business rules in a visual
way that business
analists
Post by Zhiyi Zhang
Post by christoferjennings
can modify them. Has anyone in this group used WLI or other rules
engines as part
of
Post by christoferjennings
a
Post by Zhiyi Zhang
Post by christoferjennings
domain driven design effort? or have any suggestions on good books
(hopefully
thin
Post by christoferjennings
;-) to
Post by Zhiyi Zhang
Post by christoferjennings
learn how to work effectively with rules engines?
Thanks in advance.
,boz
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links









------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Rex Madden
2004-12-20 18:20:56 UTC
Permalink
Oh, and my experience is that the business analysts will not touch the
rules. It sounds good in theory, but chances are, if they we so
simple that anyone could edit them, then you wouldn't need
programmers.
Post by christoferjennings
On the project, there seems to be a feeling (or hope anyway) that the Weblogic Integration
Platform (WLI) can be used to capture business rules in a visual way that business analists
can modify them. Has anyone in this group used WLI or other rules engines as part of a
domain driven design effort? or have any suggestions on good books (hopefully thin ;-) to
learn how to work effectively with rules engines?
Thanks in advance.
,boz
------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Shane Mingins
2004-12-20 19:11:36 UTC
Permalink
Post by Rex Madden
Oh, and my experience is that the business analysts
will not touch the
rules. It sounds good in theory, but chances are,
if they we so
simple that anyone could edit them, then you
wouldn't need
programmers.
That seems to be a shared experience. "Oh if we put
the rules in a rules engine then non-programmers can
change them."

But as soon as a rule becomes mildy complex you need
someone "smarter-than-your-average-bear" AND you have
also added another skill set dependency.

I too would be shy of using a rules engine.

Shane

=====

Shane Mingins

***@yahoo.com.clothes

please remove clothes before emailing


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
christoferjennings
2004-12-20 21:15:40 UTC
Permalink
Rex & Shane,

I'm glad you brought this up. I haven't used rules engines yet so it's
nice to hear from some who have. (And I like the Yogi Bear impression :-)

My gut tells me you're right about the Business Analysts working on
the rules -- that is, NOT actually working on the rules by themselves.
It sounds like a bad idea to have someone changing something as
important as a business rules without serious input from a business
expert AND a software expert (not to mention legal etc.). The software
supporting the business rules can't be written with foreknowledge of
all possible business rule combinations, so semantic bugs would
probably creap in that could cause serious problems. ... In any case
the systems would have to be well tested for new rule combinations.

That isn't to say that rules engines can't be used to make the process
easier. If they can, then their worth considering. As usual, it
depends on the situation.

If I see a way to define the business rules in the domain model
(and/or service layer) that makes sense to business analysts, I'll be
a happy camper. I've been told that the business rules are complex and
change relatively often. If a rules engine can help, well, so be it.

Steve's example using DROOLS makes me hope I can approach the problem
incrementally.

,boz
Post by Shane Mingins
Post by Rex Madden
Oh, and my experience is that the business analysts
will not touch the
rules. It sounds good in theory, but chances are,
if they we so
simple that anyone could edit them, then you
wouldn't need
programmers.
That seems to be a shared experience. "Oh if we put
the rules in a rules engine then non-programmers can
change them."
But as soon as a rule becomes mildy complex you need
someone "smarter-than-your-average-bear" AND you have
also added another skill set dependency.
I too would be shy of using a rules engine.
Shane
=====
Shane Mingins
please remove clothes before emailing
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Rex Madden
2004-12-20 21:38:01 UTC
Permalink
Sure, it can certainly make life easier - I'm just skeptical.
Personally, I think if you stick with a good object model, you'll be
fine in most cases. But like you said, it depends on the situation.
I'm just saying that you should err on the side of caution and start
evolving the software using basic tools. You'll still be able to
switch to an engine if/when you feel the time is right.

Also, since you said the system will have to be well tested, something
like FIT will certainly come in handy. I think that using a framework
like that can help communicate the rules and demonstrate their
validity to the BAs. In fact, you can argue that since they are
defining the rules via the tests, FIT becomes your rules engine - it's
just a matter of the developers implementing them behind the scenes,
be it via objects or some sort of actual rules engine.
Post by christoferjennings
That isn't to say that rules engines can't be used to make the process
easier. If they can, then their worth considering. As usual, it
depends on the situation.
If I see a way to define the business rules in the domain model
(and/or service layer) that makes sense to business analysts, I'll be
a happy camper. I've been told that the business rules are complex and
change relatively often. If a rules engine can help, well, so be it.
Steve's example using DROOLS makes me hope I can approach the problem
incrementally.
,boz
Post by Shane Mingins
Post by Rex Madden
Oh, and my experience is that the business analysts
will not touch the
rules. It sounds good in theory, but chances are,
if they we so
simple that anyone could edit them, then you
wouldn't need
programmers.
That seems to be a shared experience. "Oh if we put
the rules in a rules engine then non-programmers can
change them."
But as soon as a rule becomes mildy complex you need
someone "smarter-than-your-average-bear" AND you have
also added another skill set dependency.
I too would be shy of using a rules engine.
Shane
=====
Shane Mingins
please remove clothes before emailing
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
christoferjennings
2004-12-20 22:16:06 UTC
Permalink
FIT? Haven't heard that one before. Got a link?
Thanks Rex!
,boz
Post by Rex Madden
Also, since you said the system will have to be well tested, something
like FIT will certainly come in handy. I think that using a framework
like that can help communicate the rules and demonstrate their
validity to the BAs. In fact, you can argue that since they are
defining the rules via the tests, FIT becomes your rules engine - it's
just a matter of the developers implementing them behind the scenes,
be it via objects or some sort of actual rules engine.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Michael Schuerig
2004-12-20 21:54:33 UTC
Permalink
That seems to be a shared experience.  "Oh if we put
the rules in a rules engine then non-programmers can
change them."
Yes, and then all hell breaks loose.

There seems to lurk the misguided assumption that programmers are only
needed because current programming languages are just too complicated,
to fraught with details, for domain experts to use them.

The basics of mainstream programming languages such as Java are hardly
beyond the intellectual capacities of generally intelligent people. If
reading a Java book was all that stood between a domain expert and a
working application -- well, then programmers would have been
superfluous for a long time. Incidentally, we still seem to be needed
for bringing a specific qualification to the task that experts from
other areas apparently don't have.
But as soon as a rule becomes mildy complex you need
someone "smarter-than-your-average-bear" AND you have
also added another skill set dependency.
I don't think of this as matter of smartness. It's experience with the
problems, practices, and tools of the programming trade.

Michael
--
Michael Schuerig Life is just as deadly
mailto:***@schuerig.de As it looks
http://www.schuerig.de/michael/ --Richard Thompson, Sibella


------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Rex Madden
2004-12-20 18:17:56 UTC
Permalink
I would think that a rules engine is something I would refactor
towards. Start with Domain Driven Design, then if the rules REALLY
ARE that complex, you could always start moving logic from the objects
to the rules. If you go into it thinking you need a rules engine, it
seems you will be stuck with it.


On Sat, 18 Dec 2004 22:58:20 -0000, christoferjennings
Post by christoferjennings
Has anyone in this group used rules engines with DDD?
I'm just starting work on a custom J2EE stock trading application where employees can
purchase and sell stocks of their company periodically. At first glance it seem slike it
should be simple but I've been told that there is a lot of complexity driven by business
rules. The rules have evolved over years at the company, and I don't understand them yet.
On the project, there seems to be a feeling (or hope anyway) that the Weblogic Integration
Platform (WLI) can be used to capture business rules in a visual way that business analists
can modify them. Has anyone in this group used WLI or other rules engines as part of a
domain driven design effort? or have any suggestions on good books (hopefully thin ;-) to
learn how to work effectively with rules engines?
Thanks in advance.
,boz
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
m***@joxo.co.uk
2004-12-20 19:23:10 UTC
Permalink
Domain objects and rule-engine rules both by their very nature may contain
business logic. By delegating rule object responsibilties to domain objects
you can get around this to some extent.

A good example is the concept of a product and when a new product is added
to a system. "How easily can I add a new product to the system?" is often
key a business question. In this thread, the scenario appears to be
(slightly generalising) "How easily can i add/modify/remove a business rule
for a particular XXXX in the system".

Within DDD the logic for this resides in the product itself (domain logic)
or in a policy object associated to the new product. Within a rules driven
approach - the new product has a set of rules (maybe new rules, maybe
existing rules just applied to this product). Both promote good structure
and reuse of existing business logic.

Combining the two involves the product entity delegating certain requests to
a rules service that examines for example the product type and then executes
a ruleset (a set of rules) for this. The responsibilities of an individual
rule will require it to invoke methods on domain objects. I'd keep the rules
themselves simple delegating their tasks to objects that have no concept of
rules engines. The rules you define may turn out to be at a more detailed
level than those specified by the business - you then have to have the
concept of higher-level rules that matches the rules that the business
analysts will mention.

Steve - perhaps consider the rules engine as a client for your question
about how to access domain objects from within a rule.

I'm priviledged enough to a member of the JSR-94 expert group. The link is
here: http://www.javarules.org/.

The vision is here:
http://www.javarules.org/modules.php?op=modload&name=News&file=article&sid=1
6

There are products described here that may meet the business requirements of
having business analysts modify (and also create?) rules. Some of this
depends on how much the project wants to spend on such a product vs the cost
of having developers add rules. I share Rex's experiences.




Regards,
Manoj Kochhar

-----Original Message-----
From: Rex Madden [mailto:***@gmail.com]
Sent: 20 December 2004 18:21
To: ***@yahoogroups.com
Subject: Re: [domaindrivendesign] rules engines



Oh, and my experience is that the business analysts will not touch the
rules. It sounds good in theory, but chances are, if they we so
simple that anyone could edit them, then you wouldn't need
programmers.
Post by christoferjennings
On the project, there seems to be a feeling (or hope anyway) that the
Weblogic Integration
Post by christoferjennings
Platform (WLI) can be used to capture business rules in a visual way
that business analists
Post by christoferjennings
can modify them. Has anyone in this group used WLI or other rules
engines as part of a
Post by christoferjennings
domain driven design effort? or have any suggestions on good books
(hopefully thin ;-) to
Post by christoferjennings
learn how to work effectively with rules engines?
Thanks in advance.
,boz
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Molitor, Stephen L
2004-12-20 22:24:20 UTC
Permalink
http://fit.c2.com

It's great.

Steve (not Rex)

-----Original Message-----
From: christoferjennings [mailto:***@yahoo.com]
Sent: Monday, December 20, 2004 4:16 PM
To: ***@yahoogroups.com
Subject: [domaindrivendesign] Re: rules engines



FIT? Haven't heard that one before. Got a link?
Thanks Rex!
,boz
Post by Rex Madden
Also, since you said the system will have to be well tested, something
like FIT will certainly come in handy. I think that using a framework
like that can help communicate the rules and demonstrate their
validity to the BAs. In fact, you can argue that since they are
defining the rules via the tests, FIT becomes your rules engine - it's
just a matter of the developers implementing them behind the scenes,
be it via objects or some sort of actual rules engine.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links









------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Molitor, Stephen L
2004-12-20 22:55:27 UTC
Permalink
In fact, you can argue that since they are defining
the rules via the tests, FIT becomes your rules engine -
it's just a matter of the developers implementing them
behind the scenes, be it via objects or some sort of actual
rules engine.
I agree. I do have a question though. Which would provide a more
direct representation of rules described in FIT documents: expressing
them as rules in a rules engine, or as classes in an OO language? My
guess is that, in many cases at least, a rules engine would provide a
more transparent mapping between the requirements as expressed and
understood by users in FIT docs, and their implementation in code. Not
that customers would be *writing* the code (rules or whatever). But
direct mapping of domain concepts to implementation is valuable. That
is the original motivation behind OO and domain models, of course. I've
always resisted introducing a rules engine because I've felt that with a
good domain model you wouldn't need one. But maybe object bigots like
myself need to be a bit more open minded!

Steve

-----Original Message-----
From: Rex Madden [mailto:***@gmail.com]
Sent: Monday, December 20, 2004 3:38 PM
To: ***@yahoogroups.com
Subject: Re: [domaindrivendesign] Re: rules engines


Sure, it can certainly make life easier - I'm just skeptical.
Personally, I think if you stick with a good object model, you'll be
fine in most cases. But like you said, it depends on the situation.
I'm just saying that you should err on the side of caution and start
evolving the software using basic tools. You'll still be able to switch
to an engine if/when you feel the time is right.

Also, since you said the system will have to be well tested, something
like FIT will certainly come in handy. I think that using a framework
like that can help communicate the rules and demonstrate their validity
to the BAs. In fact, you can argue that since they are defining the
rules via the tests, FIT becomes your rules engine - it's just a matter
of the developers implementing them behind the scenes, be it via objects
or some sort of actual rules engine.
That isn't to say that rules engines can't be used to make the process
easier. If they can, then their worth considering. As usual, it
depends on the situation.
If I see a way to define the business rules in the domain model
(and/or service layer) that makes sense to business analysts, I'll be
a happy camper. I've been told that the business rules are complex and
change relatively often. If a rules engine can help, well, so be it.
Steve's example using DROOLS makes me hope I can approach the problem
incrementally.
,boz
Post by Rex Madden
Oh, and my experience is that the business analysts will not touch
the rules. It sounds good in theory, but chances are, if they we
so simple that anyone could edit them, then you wouldn't need
programmers.
That seems to be a shared experience. "Oh if we put the rules in a
rules engine then non-programmers can change them."
But as soon as a rule becomes mildy complex you need someone
"smarter-than-your-average-bear" AND you have also added another
skill set dependency.
I too would be shy of using a rules engine.
Shane
=====
Shane Mingins
please remove clothes before emailing
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->


Yahoo! Groups Links









------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Rex Madden
2004-12-20 23:12:50 UTC
Permalink
Absolutely right. Just make sure that the burden of proof is on the
rules engine, not the object model.

On Mon, 20 Dec 2004 16:55:27 -0600, Molitor, Stephen L
Post by Molitor, Stephen L
I agree. I do have a question though. Which would provide a more
direct representation of rules described in FIT documents: expressing
them as rules in a rules engine, or as classes in an OO language? My
guess is that, in many cases at least, a rules engine would provide a
more transparent mapping between the requirements as expressed and
understood by users in FIT docs, and their implementation in code. Not
that customers would be *writing* the code (rules or whatever). But
direct mapping of domain concepts to implementation is valuable. That
is the original motivation behind OO and domain models, of course. I've
always resisted introducing a rules engine because I've felt that with a
good domain model you wouldn't need one. But maybe object bigots like
myself need to be a bit more open minded!
Steve
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
christoferjennings
2004-12-30 02:33:55 UTC
Permalink
First,: Thanks to everyone for the good discussion on rule engines!

Second: It kinda ended with a split, I think.

It sounds like Manoj suggests keeping the business logic in the domain model while Rex
seems to suggest keeping the logic in the rules....

Manoj: "The responsibilities of an individual rule will require it to invoke methods on
domain objects. I'd keep the rules themselves simple delegating their tasks to objects that
have no concept of rules engines."

Rex: " Just make sure that the burden of proof is on the rules engine, not the object
model."

Is it just that there's two way to do it, just don't mix them? Or did I miss something and
you're each actually saying the same thing?

For what it's worth, after the thread and reading about Specification again I'm leaning
toward a rich domain model with rules in Specifications. Keeping it all together (and not
using a rules engine) seems like it will make it easier to talk about. ... Now if I can just
convince the rest of my team. :-)

,boz





------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Rex Madden
2004-12-30 14:13:16 UTC
Permalink
Actually, by burden of proof, I meant that the Rules Engine should
need to prove it's worth before deciding to use it. Keeping as much
logic as possible in the object model should be the default. But if
you find that a Rules Engine can help communicate the rules in a
better manner than plain objects, then you can give it a try.


On Thu, 30 Dec 2004 02:33:55 -0000, christoferjennings
Post by christoferjennings
First,: Thanks to everyone for the good discussion on rule engines!
Second: It kinda ended with a split, I think.
It sounds like Manoj suggests keeping the business logic in the domain model while Rex
seems to suggest keeping the logic in the rules....
Manoj: "The responsibilities of an individual rule will require it to invoke methods on
domain objects. I'd keep the rules themselves simple delegating their tasks to objects that
have no concept of rules engines."
Rex: " Just make sure that the burden of proof is on the rules engine, not the object
model."
Is it just that there's two way to do it, just don't mix them? Or did I miss something and
you're each actually saying the same thing?
For what it's worth, after the thread and reading about Specification again I'm leaning
toward a rich domain model with rules in Specifications. Keeping it all together (and not
using a rules engine) seems like it will make it easier to talk about. ... Now if I can just
convince the rest of my team. :-)
,boz
Yahoo! Groups Links
------------------------ Yahoo! Groups Sponsor --------------------~-->
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Loading...