Are There Best Practices for (Java) Package Organization

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.

Package structure for a Java project?

You could follow maven's standard project layout. You don't have to actually use maven, but it would make the transition easier in the future (if necessary). Plus, other developers will be used to seeing that layout, since many open source projects are layed out this way,

What is the recommended project structure for spring boot rest projects?

You do not need to do anything special to start. Start with a normal java project, either maven or gradle or IDE project layout with starter dependency.

You need just one main class, as per guide here and rest...

There is no constrained package structure. Actual structure will be driven by your requirement/whim and the directory structure is laid by build-tool / IDE

You can follow same structure that you might be following for a Spring MVC application.

You can follow either way

• A project is divided into layers:
  

  for example: DDD style

  • Service layer : service package contains service classes
  • DAO/REPO layer : dao package containing dao classes
  • Entity layers

  
  or
  

  any layer structure suitable to your problem for which you are writing problem.
  
  

• A project divided into modules or functionalities or features and A module is divided into layers like above

I prefer the second, because it follows Business context. Think in terms of concepts.

What you do is dependent upon how you see the project. It is your code organization skills.

Java project structure explained for newbies?

"Simple" J2SE projects

As cletus explained, source directory structure is directly equivalent to package structure, and that's essentially built into Java. Everything else is a bit less clear-cut.

A lot of simple projects are organized by hand, so people get to pick a structure they feel OK with. What's often done (and this is also reflected by the structure of projects in Eclipse, a very dominant Java tool) is to have your source tree begin in a directory called src. Your package-less source files would sit directly in src, and your package hierarchy, typically starting with a com directory, would likewise be contained in src. If you CD to the src directory before firing up the javac compiler, your compiled .class files will end up in the same directory structure, with each .class file sitting in the same directory and next to its .java file.

If you have a lot of source and class files, you'll want to separate them out from each other to reduce clutter. Manual and Eclipse organization often place a bin or classes directory parallel to src so the .class files end up in a hierarchy that mirrors that of src.

If your project has a set of .jar files to deliver capability from third-party libraries, then a third directory, typically lib, is placed parallel to src and bin. Everything in lib needs to be put on the classpath for compilation and execution.

Finally, there's a bunch of this and that which is more or less optional:

• docs in doc
• resources in resources
• data in data
• configuration in conf...

You get the idea. The compiler doesn't care about these directories, they're just ways for you to organize (or confuse) yourself.

J2EE projects

J2EE is roughly equivalent to ASP.NET, it's a massive (standard) framework for organizing Web applications. While you can develop your code for J2EE projects any way you like, there is a firm standard for the structure that a Web container will expect your application delivered in. And that structure tends to reflect back a bit to the source layout as well.
Here is a page that details project structures for Java projects in general (they don't agree very much with what I wrote above) and for J2EE projects in particular:

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Maven projects

Maven is a very versatile project build tool. Personally, my build needs are nicely met by ant, which roughly compares with nmake. Maven, on the other hand, is complete-lifecyle build management with dependency management bolted on. The libs and source for most of the code in the Java world is freely available in the 'net, and maven, if asked nicely, will go crawling it for you and bring home everything your project needs without you needing to even tell it to. It manages a little repository for you, too.

The downside to this highly industrious critter is the fact that it's highly fascist about project structure. You do it the Maven way or not at all. By forcing its standard down your throat, Maven manages to make projects worldwide a bit more similar in structure, easier to manage and easier to build automatically with a minimum of input.

Should you ever opt for Maven, you can stop worrying about project structure, because there can only be one. This is it: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

---

Related Topics