The Interaction-Flow-Service-Model Architectural Pattern
There is one thing that I've overlooked until today, which is the importance of the division of the controller into application "flow(s)" and application "service(s)". For a good while now, I had been keeping controller code separate from service code (which in turn called the DAOs, that used Spring DAO, that used Hibernate, that interacted with the DB, etc.). However sometimes business logic that should probably be in those services can easily blur into the controller classes, which are sometimes also at least in part, responsible for the flow.
Until you try to replace the part of the app handling the flow, maybe you're fine, as many are! However, there is a big wave headed your way, that you've felt coming for a good while now (and some have been dunked!) which is "flow".
I started a few days ago to take an application I had written and convert it to Spring Web Flow 2. While writing the flows for the application, it stood out to me clearly how many methods were missing from the service layer of my application that I planned to call from the flows, and the additional pain that will come with moving that code from the controller and other related classes (injected instances in the controller and sometimes utility classes).
Are we moving towards what possibly could be called a "Interaction-Flow-Service-Model" (IFSM) architectural pattern? (Which is updating the lingo a little in model-view-controller and separating the "controller" part concept into "flow" and "service"?)
Throwing this out there, and would appreciate any comments.