Oct 28, 2008 / .net ~ workflow
Little Workflows?

Disclaimer: I have no experience using workflows in applications :)

I've been thinking about what I want to get out of workflows and state machines. Or even, what value can they add to my applications.

Workflows seem under-used. Windows Workflow doesn't seem to encourage prolific use. Setting up a workflow is a bit of a plumbing exercise, or so it seems?

I like the idea of having lots of light-weight workflows that can be created and consumed with very little effort (minutes of coding). They'd almost be like a first-class citizen in the language. I'd see them cropping up all over the place: workflows to govern GUI sequences. Workflows inside GUI controls to govern their current state. Workflows internal to domain entities used prevent execution of business logic at the wrong time.

I like the idea that, whenever I need to constrain when business logic is allowed to execute, I can create a workflow to describe that. So, business logic related to sequencing of events lives in, err, a workflow. But only that logic, not the other stuff.

This is a separation of concerns, the workflow is responsible for containing business rules related to what can be done and when it can be done, and possibly even by whom it can be done. This may keeps workflows light because they're not trying to do too much.

I also like the idea of a GUI observing a workflow, just as it does with other models, and use it to dictate the options that are presented to the user.

This is a bit of a waffling post. Again, I've got no experience with this, sorry if I'm talking crap!

With that in mind, does anyone know of any good articles/books defining proven patterns for using workflows in applications?

Is anyone using an abundance of light (or heavy) workflows in their applications?


You may also like...