Are there best practices for Java package organization

Question

A little while ago  I saw a question answered here regarding the fine-grained organization of java packages   For example  my project util  my project factory  my project service  etc   I can t find it now  so I may as well ask the question   Are there best practices with regards to the organization of packages in Java and what goes in them   How do you organize your classes in your Java project     For instance  a project I m working on with a few people has a package called beans  It started out being a project containing simple beans  but has ended up  through poor experience and lack of time  containing everything  almost    I ve cleaned them up a little  by putting some factory classes in a factory package  classes with static methods that create beans  but we have other classes that do business logic and others that do simple processing  not with business logic  like retrieving a message for a code from a properties file   Your thoughts and comments are appreciated

User · Answer

I ve seen some people promote  package by feature  over  package by layer  but I ve used quite a few approaches over many years and found  package by layer  much better than  package by feature    Further to that I have found that a hybrid   package by module  layer then feature  strategy works extremely well in practice as it has many advantages of  package by feature     Promotes creation of reusable frameworks  libraries with both model and UI aspects  Allows plug and play layer implementations - virtually impossible with  package by feature  because it places layer implementations in same package directory as model code  Many more      I explain in depth here  Java Package Name Structure and Organization but my standard package structure is   revdomain moduleType moduleName layer  layerImpl  feature subfeatureN subfeatureN 1     Where   revdomain Reverse domain e g  com mycompany  moduleType  app  framework util   moduleName e g  myAppName if module type is an app or  finance  if its an accounting framework  layer  model ui persistence security etc     layerImpl eg   wicket  jsp  jpa  jdo  hibernate  Note  not used if layer is model   feature eg   finance  subfeatureN eg   accounting  subfeatureN 1 eg   depreciation   Sometimes  app  left out if moduleType is an application but putting it in there makes the package structure consistent across all module types

User · Answer

I m not aware of standard practices for package organization  I generally create packages that cover some reasonably broad spectrum  but I can differentiate within a project  For example  a personal project I m currently working on has a package devoted to my customized UI controls  full of classes subclassing swing classes   I ve got a package devoted to my database management stuff  I ve got a package for a set of listeners events that I ve created  and so on  On the other hand I ve had a coworker create a new package for almost everything he did  Each different MVC he wanted got its own package  and it seemed a MVC set was the only grouping of classes allowed to be in the same package  I recall at one point he had 5 different packages that each had a single class in them  I think his method is a little bit on the extreme  and the team forced him to reduce his package count when we simply couldn t handle it   but for a nontrivial application  so would putting everything in the same package  It s a balance point you and your teammates have to find for yourself  One thing you can do is try to step back and think  if you were a new member introduced to the project  or your project was released as open source or an API  how easy difficult would it be to find what you want  Because for me  that s what I really want out of packages  organization  Similar to how I store files in folder on my computer  I expect to be able to find them again without having to search my entire drive  I expect to be able to find the class I want without having to search the list of all classes in the package

User · Answer

Short answer  One package per module feature  possibly with sub-packages  Put closely related things together in the same package  Avoid circular dependencies between packages   Long answer  I agree with most of this article

User · Answer

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 feature       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

User · Answer

Are there best practices with regards to the organisation of packages in Java and what goes in them    Not really no   There are lots of ideas  and lots opinions  but real  best practice  is to use your common sense      Please read No best Practices for a perspective on  best practices  and the people who promote them    However  there is one principal that probably has broad acceptance   Your package structure should reflect your application s  informal  module structure  and you should aim to minimize  or ideally entirely avoid  any cyclic dependencies between modules      Cyclic dependencies between classes in a package   module are just fine  but inter-package cycles tend to make it hard understand your application s architecture  and can be a barrier to code reuse   In particular  if you use Maven you will find that cyclic inter-package   inter-module dependencies mean that the whole interconnected mess has to be one Maven artifact    I should also add that there is one widely accepted best practice for package names   And that is that your package names should start with your organization s domain name in reverse order   If you follow this rule  you reduce the likelihood of problems caused by your  full  class names clashing with other peoples

User · Answer

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

User · Answer

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

[java] Are there best practices for (Java) package organization?

Examples related to java

Examples related to package

Examples related to naming-conventions