To clarify, the data is the process definitions, or the rules that govern what happens under which circumstances. The code is spread between the workflow engine and process state tracking. That's definitely a helpful way of looking at it, although writing an engine to parse a custom rule-set is (I believe anyway) a very serious undertaking. But maybe that's why you're suggesting a compromise between a full workflow engine and hardcoding behavior? That feels right to me, especially since I strongly advocate the "build one to throw away" school of thought, and this is a first brush at something that will likely be reworked at some point.
I liked this quote from that IBM document: "Effective workflow processes have three basic components: data, process logic, and a directory of participants." (pg. 2)
Thanks diotalevi.
In reply to Re: Re: Decision Trees and the Strategy Design Pattern
by djantzen
in thread Decision Trees and the Strategy Design Pattern
by djantzen
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |