Modules vs Layers in Java Package Structure

Question

I used to put everything in such packages:

com.company.app.module1 com.company.app.module2 

But he made package-based AOP pointputs complex and led to huge packages that needed an IDE to understand.

So now I understand that I need a deeper packaging structure, but I'm constantly torn. Prefer module preference?

 com.company.app.module1.domain com.company.app.module1.logic com.company.app.module1.persistence com.company.app.module2.domain com.company.app.module2.logic com.company.app.module2.persistence 

or provide layer preferences, for example:

 com.company.app.domain.module1 com.company.app.domain.module2 com.company.app.logic.module1 com.company.app.logic.module2 com.company.app.persistence.module1 com.company.app.persistence.module2 

Pros and cons of each?

Answer 1

Modules First.

I had a project that was originally a layer, but it became too cumbersome to read and maintain, so we reorganized it. He also used AOP - no problem. We just used .. in the middle of the package definition (we used spring aop with aspectj syntax). Here's what it looks like:

 execution(* com.foo.app.modules..service..*.*(..)) 

This corresponds to both modules.module1.service and modules.module2.service

Answer 2

The modular organization allows developers to focus on feature sets as a delivery unit rather than a technical infrastructure. Scaling the code base is probably easier if you break the work on the basis of modules - some open source projects whose code I was looking at (for example, Artifactory and Continuum) organized such things in this way, but I did not look enough. to find out is a general trend.

This probably depends on the size of the code base.

Answer 3

I admit that I have never done much (formal) AOP.

Personally, I would first put the modules.

Thus, if you later divide the modules into several JAR / WAR files (for example, to a separate maven project), they are already in the correct directory structure to separate them by module.

Answer 4

I would organize the hierarchy of packages by level so that your tools work. Each module will go into its own project with its own source folder. This gives your IDE and developers easy grouping by modulus, but your runtime tools are easily grouped into layers.

Answer 5

I would rather put the module, but it seems to me that you should all refer to everything. This could be the reason for such confusion among developers.