Are there best practices for (Java) package organization?

Package organization or package structuring is usually a heated discussion. Below are some simple guidelines for package naming and structuring:

• Follow java package naming conventions
• Structure your packages according to their functional role as well as their business role
  • Break down your packages according to their functionality or modules. e.g. com.company.product.modulea
  • Further break down could be based on layers in your software. But don't go overboard if you have only few classes in the package, then it makes sense to have everything in the package. e.g. com.company.product.module.web or com.company.product.module.util etc.
  • Avoid going overboard with structuring, IMO avoid separate packaging for exceptions, factories, etc. unless there's a pressing need.
• If your project is small, keep it simple with few packages. e.g. com.company.product.model and com.company.product.util, etc.
• Take a look at some of the popular open source projects out there on Apache projects. See how they use structuring, for various sized projects.
• Also consider build and distribution when naming ( allowing you to distribute your api or SDK in a different package, see servlet api)

After a few experiments and trials you should be able to come up with a structuring that you are comfortable with. Don't be fixated on one convention, be open to changes.

I organize packages by feature, not by patterns or implementation roles. I think packages like:

• beans
• factories
• collections

are wrong.

I prefer, for example:

• orders
• store
• reports

so I can hide implementation details through package visibility. Factory of orders should be in the orders package so details about how to create an order are hidden.