It is amazing that there are still architects designing and advising J2EE architecture patterns when creating typical server-based applications with Java. Before you think “OMG maybe I’m doing it also!”, I’ll give you a few of these practices:
- J2EE application server is the fundament providing all the technologies needed by your application and your application relies upon; instead of other way around: your application might use some of J2EE technologies, Spring or other framework, or combination to deliver functionality.
- Two-phase commit transaction management, which is just wrong from the beginning as a concept.
- System is designed by using standard multi-tier model (client, presentation, business, integration, data, resource) and placing code mainly in different kinds of EJB’s.
Many also emphasize core J2EE patterns like “front controller”, “business delegate”, “session facade” as the main drive force behind good design. They forget that these patterns have almost nothing to do with object orientation and do not manage any domain complexity. It is all technical, often only needed because of the overuse of J2EE technologies and all those tiers. You want to learn really useful design practices? Read: Domain Driven Design from Eric Evans.
Grab any possible chance, while you can, to get rid of all those tiers. Always search for simpler solution, even if not J2EE standardized. Reduce your dependency on application server technologies as much as possible. The code that provides business functionality should be free of any technical stuff like transaction management, EJB, SOAP, clustering, caching, integration.
This will make your system less likely to become painful legacy, ready to be replaced in the future when application servers look completely different or are not important at all.
LeanArch.eu 
Hi,Excellent write up about the way "Old School" is clinging on to ideas.I am currently in a project that is planned to be used as a platform and slowly so many things like complexity, adaptability to changes is slowly becoming a big concern.. Is there anything specific you can suggest than can help me learn better and work towards making my existing system more flexible and adapatable to changes?
Hi Suresh,Thanks! It is difficult to advise something really useful without knowing the context. But still, I would suggest to let go of "making system more flexible". Flexibility in itself does not mean much. Even within a context, it is quite difficult to define what exactly need to be flexible and how. For me, flexibility is just part of implementation of each separate function requested and connected to business need."Adaptable to changes" has in practice pretty much the same meaning as simplicity. If some solution is very simple and straight forward, then it is cheap to replace it too. In other words, I never design systems that should meet changing requirements, but design and system itself should be easy to change with those requirements.