Project structure
I highly recommend that you follow the Maven rules for the structure: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html They are the result of many years of experience.
However, designing such a structure is always a compromise between extensibility and simplicity. The more you foresee, the more difficult it will be to maintain, but the more you return your investment, the faster it will grow.
To be pragmatic, and even I'm not very convinced (because my job is to anticipate;)), try the KISS philosophy: http://en.wikipedia.org/wiki/KISS_principle .
Package structure
As Amandeep Jiddewar said, packages should present their own functionality. At the very least, they should be reverse domains, such as: http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html . For example, the stackoverflow API should be: com.stackoverflow. *
And maybe for the first time they immersed it in an MVC pattern
- com.stackoverflow.controler
- com.stackoverflow.model
- com.stackoverflow.view
etc.
And when the project was mature ... or grew too much, they divided it into war for the presentation layer and jar (s) for the service level ...
Further considerations
There is no special rule. As I said, you always have to deal with a compromise. Only experience will give you the opportunity to find out when you need to change the configuration.
Look around for more ideas: naming-conventions
source share