jBPM and Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 407

Figure 11-1. The two roles(user, and system) are shown as swimlanes. Rounded shapes inside the
swimlanes are states. Process flows from one state to another, following the path of the connecting lines.
For such a simple process, it might be tempting to keep track of the state of the process in the
domain model. After all, some of the state, such as the sign-up date, can certainly be regarded as
business data, belonging to model entities. Such a date is valuable for revenue recognition. The date
when the welcome e-mail was sent is probably not very important, though. The situation will escalate
if you send out more e-mails. If you build other kinds of processes involving the user, then management
of the user's state within those processes will become a burden on your system and will complicate
the schema.
A workflow system extricates that process state from the domain and into a separate layer, called a
business process. A workflow system also typically models which agents in the system do what work,
providing work lists for different agents in the system.
A workflow engine lets you model the process in a higher-level form, roughly corresponding in code
what a UML activity diagram can describe. Because a workflow is high-level, specifying how a business
process is leveraged as an executable component of a system is a dizzyingly vast task. In industry, there
are standards for the language used to model a business process as well as the model of the engine that's
used to run the business process. Additionally, there are standards specifying interoperability, how
endpoints are mapped to the agents being orchestrated by the process, and much more. Indeed, it can
quickly become overwhelming.