As I understand it, it's generally recommended to package by feature rather than by layer. This promotes higher levels of abstraction and modularity between classes.

I can understand how this works in regular non-utility applications where it has clear features (registration, security, etc), but it is hard to apply this to static utility libraries.

For example, take a look Google Guava's packaging structure. As it is a library, it is hard to categorize the features of the library into packages. There is an annotations package, a networking package, etc. This feels like a bit of a grey-zone to me as it isn't packaged in an explicit format?

What is the general consensus when packaging by feature for something which consists of utility classes (such as a library/API)?


The general consensus probably does not exist. Logically, it makes no sense to follow the general consensus anyway. You should package according to the abstractions that make most sense for users of the library. If you are creating a low level library, the abstractions should be low-level.

The word "features" does not have much meaning in your question. Are they application-level features? If so, that might make sense for an application level library, but not for any other type of library.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.