Java EE – Best Practice Tier Structure for Java EE 6/7 Applications

Tackling a significant refactor requires you to have a solid understanding as to why you're performing that refactor.

I'll rule out the hobby level justifications such as "make the code more pure" or "improve stylistic expression" or similar. Those aren't bad justifications, but a commercial project will almost never see or use that level of justification for a major undertaking.

In contrast, commercial level refactoring justification always involves pain.

• "Maintenance has become impossible."
• "The code base can't be extended."
• "Code changes generate obscure errors in unanticipated areas of the code."

Pain justifies the expense and risk involved. And pain leads you to your answer. You refactor in order to minimize future pain. Refactor in order to encapsulate the change.

You mentioned a couple of aspects such as communication systems, orders, and shipments. And you correctly called out that there isn't a one-size-fits-all approach to identify what belongs where. Every system is different based upon its domain and business need.

For your system, identify what is changing. Push that into its own vertical that conforms to a contract or an API with the rest of the system. Whenever that section changes, you can verify it still meets its contract and control the amount of damage from the code change.

There are several advantages to this approach:-

• Responsiveness, because the business logic is in the fat client you do not need to wait for a round trip over the network for every interaction.
• Sophistication - having all the control and higher level logic in the client enables rich user interfaces (e.g. this site, or gmail) which would simply not be possible if every interaction required a round trip to the server.
• Scalability, all this processing is taking place on your device, using your electricity. if you have a large number of users the saving in server side processing is significant.

There are a few downsides though.

• Lack of control over the client environment. You do not know which browser on which OS or what screen size and processing power your client will have. You application may not work on every client.
• Uneven response. Large client libraries need to be downloaded and upgraded every now and then which will be relatively slow, once downloaded the response is lightning fast, users, generally prefer a consistent response time even if it is a little slower.
• Javascript -- love it or hate it you are stuck with it as your main development language. Your code becomes public which some companies hate (perhaps they are embarrassed by their code quality?).
• Security -- your server side code is now largely just database services whose APIs are open to anyone studying your Javascript therefore you need to take extra care in securing these services.