Java package organization

java package.txt

Source: http://stackoverflow.com/questions/3226282/are-there-best-practices-for-java-package-organisation
Credits: http://stackoverflow.com/users/2316982/thomasgran

I prefer feature before layers, but I guess it depends on you project. Consider your forces:

* Dependencies. Try minimize package dependencies, especially between features. Extract APIs if necessary.

* Team organization. In some organizations teams work on features and in others on layers. This influence how code is organized, 
use it to formalize APIs or encourage cooperation.

* Deployment and versioning. Putting everything into a module make deployment and versioning simpler, but bug fixing harder. 
Splitting things enable better control, scalability and availability.

* Respond to change. Well organized code is much simpler to change than a big ball of mud.

* Size (people and lines of code). The bigger the more formalized/standardized it needs to be.

* Importance/quality. Some code is more important than other. APIs should be more stable then the implementation. Therefore it needs 
to be clearly separated.

* Level of abstraction and entry point. It should be possible for an outsider to know what the code is about, and where to start 
reading from looking at the package tree.

Example:

com/company/module
  + feature1/
    - MainClass          // The entry point for exploring
    + api/               // Public interface, used by other features
    + domain/
      - AggregateRoot
      + api/             // Internal API, complements the public, used by web
      + impl/ 
    + persistence/       
    + web/               // presentation layer 
    + services/          // Rest or other remote API 
    + support/            
  + feature2/
  + support/             // Any support or utils used by more than on feaure
    + io
    + config
    + persistence
    + web
    
This is just an example. It is quite formal. For example it defines 2 interfaces for feature1. Normally that is not required, 
but could be a good idea if used differently by different people. You may let the internal api extend the public.

I do not like the 'impl' or 'support' names, but they help separate the less important stuff from the important (domain and api). 
When it comes to naming I like to be as concrete as possible. If you have a package called 'utils' with 20 classes, move 
StringUtils to support/string, HttpUtil to support/http and so on.