I'm starting this thread, after reading over the interesting thread:
Book: "Domain driven design" implemented in Spring
I think that we are missing something fundamental in the Spring releases, and in the software development world, in general. I'll call them "Framework Pattern Templates". If someone else has already coined that term AND these already exist for Spring, please clue me in, and the rest of this is moot:
There are just SO many different opinions and design approaches on this. I mean just look at all the different opinions on that one thread! And the essential problem is this: If you pick one design pattern over the other and implement, you won't know until production time, or at least deep in the middle of coding it all, whether the opinion/pattern you picked was a winner!
What seems, to me, to be the critical missing piece, is what I'll call a "framework pattern template".
"Framework patterns" would be analogous to the well-documented GoF patterns, except that they would be specific to the "framework", in this case, Spring. For all I know, they may already exist, and I just haven't spotted them yet in my readings. Do they?
In any case, a "framework pattern template" would be an ACTUAL RUNNABLE App (like, say, the Echo sample app I recently contributed for Spring, or the Pet Clinic sample, or the Spring Web Service Airline sample, and so on).
Notice, please, that everyone now calls these "samples", which is CLOSE to a "framework pattern template", but is not one yet. If Spring adds a "framework pattern description" for, say, a "Simple Spring JAXB Web Service", the Echo sample could then be stated as the "framework pattern template" for it. If Spring adds a framework pattern description for, say, "Spring Web Service With Hibernate-Fronted Database", the Airline sample could be the framework pattern template for that (if I'm remembering the Airline sample details correctly). The number and granularity of the Spring "framework pattern templates" would be limited only by the amount of time that Interface21 and the contributors have to contribute and maintain them.
The current problem is essentially this: We are being told by Spring to fit a round peg (say, the Pet Clinic sample) into a square hole (the app you and I are currently designing/writing). Your app often bears little resemblance to the sample given...once you finally "induce" (draw conclusions and generalizations about) the full "framework pattern" from the sample app.
For example, what if your app actually NEEDS the JSP page to scroll through 1000 rows of data, and allow the user to in-line edit 50 of the rows?
This can easily be done in some apps (such as TOAD), but what is the best (or at least a) Spring "framework pattern" for that? and where, please, is the "framework pattern template"? This would clearly answer someone's question earlier in that thread asking how would Rod or Juergen do such and such, i.e. what would Spring recommend.
In addition, the samples (all of today's vendors', i.e. not just Spring's) do not clearly separate the documentation of the "plumbing" (how it goes about wiring up its objects, resources, etc.) from the app functionality (pets). This is what makes it so hard to induce the various framework patterns and sub-patterns from the samples. There is much patterning going on in the samples that is merely implied and not stated.
If Spring can start to separate out the plumbing from the app functionality, via some kind of "framework pattern documentation", then the true "framework pattern template" begins to emerge, and becomes useful to anyone who happens to need that particular pattern.
Further, there would be much less architecural debate about how to design your layers and services and such. (That would all be stated in the "framework pattern". The debates would be more "fine-grained", about, say, how to "clone-and-morph" the existing "framework pattern template" to accomplish some exotic or unusual task.
To be fair to the Spring people, they may currently have their hands full, just moving their framework forward. I mean, I imagine they have a life, too...or...hmm...maybe they've figure out how to clone themselves.
This is where the value of framework pattern templates provided by groups such as Spring would pay off for everyone: Less time debating how to design within a framework and more time coding of cost-effective, easy-to-maintain app functionality from pre-existing framework pattern templates.