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.