Michael Nash at developer.com - Decoupling Application Logic, Persistence, and Flow: The Model Technique:

“The next step beyond separation of persistence and business logic can be the separation of the application control flow. Business logic classes in this case are written in such a way that they are unaware of how they were called, or what business logic element will be called next. They still require certain inputs, of course, and produce results in some fashion (again, often using the bean pattern to allow result properties to be accessed), but they are a single link in a chain. Some external mechanism is used to control application flow, either another class, or a driver class that reads the sequencing and navigation information from configuration.

[…] Long-time users of Unix-style operating systems will be familiar with the pattern described here, as it is a lot like the Unix command philosophy: Keep each command simple, make it do one thing and do it well, and provide a powerful means to assemble multiple commands into complex applications. In the Unix world, this is achieved by shell scripts and the pipeline technique. The same ideas can be applied to Java applications, with similar powerful results.

Many developers, of course, will recognize this technique as the beginnings of a full workflow pattern, where application logic steps can be combined in sequences or “flows” as required, and where the decisions at each step as to what the next step should be (or what the choices for next steps are, if there are several), are in fact left up to the workflow engine, driven by a sophisticated configuration file. This configuration file can even in many cases be created graphically, allowing a developer to literally draw the sequence of operations of the application required, drawing more and more from a pool of re-usable business logic components, and inventing each individual wheel only once, instead of repeatedly.”