Modules vs Layers in Java package structure

Question

I used to put everything in packages like this:

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

But it has made package-based AOP pointcuts difficult, and resulted in huge packages that need an IDE to make sense of.

So now I realize I need a deeper package structure, but I am constantly torn. Give modules preference, like this?

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 give layers preference, like this?

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 initially layer-first, but it became too bulky to read and maintain, so we refactored it. It used AOP as well - without any problems. We just used .. in the middle of the package definition (we used spring aop with aspectj syntax). Here's how it looks like:

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

This matches both modules.module1.service and modules.module2.service

Answer 2

Organizing by module allows developers to focus on feature sets as the unit of delivery rather than technical infrastructure. Scaling your code base is probably easier if you break things up based on modules - some open source projects whose code I have looked at (such as Artifactory and Continuum) organized things this way, but I haven't looked at enough to know if this is the general trend.

It probably does depend though, depending on your code base size.