Isolating Flow from Services

• All non-flow-related logic should be pushed to service layer (or an additional service-logic layer).
• Aim for simplicity in controllers and related contextual VOs. Unless something else is needed, lean towards using simple generic constructs such as a Map to store flow context.
• If persistance is required for any data (including flow-state) store and retrieve it via services and minimize and handling required in flow.
• Avoid use of complex flow logic, assumptions about flow control, and assumptions about scopes as they might be implementation-specific. The framework might offer 10 options for how to do something, but you choose the one that keeps things as simple as possible to guard against future changes.
• At times the services will need access to the original request object/external context. It is simple to wrap the request object/external context in another object that you can call to get specific information that you need from the request (like getting the remote user, getting a session param, checking a user's role, etc.), and it might save some headache later if you swap out the slow layer with another implementation that has a different concept of context.

Let's also talk about scopes in the flow layer. For the official description of how Spring Web Flow 2 handles flow scope see the Special EL variables section of their reference docs.

In Spring Web Flow 2:

• flowScope - within scope of a SWF2 "flow". Can be multiple flows per application. This is the primary scope used in SWF2. A smaller scope than web session, greater than scope of an web request.
• viewScope - scope within a SWF2 "view-state". A smaller scope than web session, greater than scope of an web request.
• requestScope - scope is from the point the flow is called until it returns. A smaller scope than web session, greater than scope of an web request.
• flashScope - variable only lives for a single render in a flow. Similar to the scope of a web request.
• conversationScope - is stored in web session, but is not equivalent to session. It only exists for as long as the top-level flow exists.

As you can see, most scopes don't really have a clear counterpart in the non-SWF2 world. The reason I mention this is that you might want try to keep scope concepts in your controller implementation simple, and when implementing any flow framework, be careful not to tie yourself tightly to flow scopes and logic that couldn't be expressed more simply. That's not so much a "flow isolation from services" thing as much as a "make sure that you understand that different flow layer solutions may handle scopes differently, so watch out" thing.

Again, I'm not an expert in Spring Web Flow 2 or the flow layer in general (I'm still learning!), so would appreciate any comments or thoughts you have on this or on implementation of IFSM.