imagine
given a project business object and such (simplified) rules:
- it’s lifecycle is divided into several
stages of evaluation; - stages flow lineary and represent an evaluation chain;
- each stage provides its own
reward value/algorithm; - promotion of the project is controlled by other user’s decision;
- the resulting reward is assigned to the project’s initiator.
too naive, probably)
The first thought that comes to my mind is using the decorator pattern; because of its structure it looks somewhat applicable. But what if you need to persist additional details provided with the current ‘decorated’ state of project?
I need an extra behavior on each stage
I’ve encountered an article about jBPM. I believe it has much in common with WF. It is surely has the most of what is needed and at the same time it has (overkill) large infrastructure.
but can it be designed without incorporating this much complexity?
What would you suggest?
2
When I see “process” that spans time, I usually think “state machine”. However, one of your requirements says the process is linear, so state machine might be overkill.
It definitely sounds like you have a common interface that describes Stage, with functions like reward(), and a top-level Project that “has a” Stage.
I’m assuming the project runs over an extended time, so you need to be able to save the project state in between events in the project. So Project would have to be persist-able, including the Stage that it’s in.
Right off the bat, I see a Project class, Stage interface, and concrete implementations of Stage. And then probably a StageId enum to make it easy to persist the stages.
(Knowing me, I’d probably also define the transitions in a map and implement a really, really simple state machine too. But the simple, linear state machine you have could just be done with if…thens to keep it light.)