我曾经把所有东西放在这样的包中：
com.company.app.module1
com.company.app.module2
但它已经使基于包的AOP切入点变得困难，并导致需要IDE理解的大型包。
所以现在我意识到我需要一个更深层的包结构，但我经常被撕裂。给出模块首选项，像这样吗？
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
或给出图层偏好，像这样？
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
各自的优点和缺点？
答案 0 :(得分：7)
模块优先。
我有一个最初是第一层的项目，但它的读取和维护太过庞大，所以我们重构了它。它也使用了AOP - 没有任何问题。我们在包定义的中间使用了..（我们使用了带有aspectj语法的spring aop）。这是它的样子：
execution(* com.foo.app.modules..service..*.*(..))
这与modules.module1.service和modules.module2.service
答案 1 :(得分：3)
按模块组织允许开发人员将功能集作为交付单元而非技术基础架构。如果你基于模块分解你的代码库可能会更容易 - 一些我看过的代码的开源项目（例如Artifactory和Continuum）以这种方式组织了东西，但是我还没有看到足够的知道是否这样是大势所趋。
它可能确实依赖于您的代码库大小。
答案 2 :(得分：2)
我承认，我从未真正做过很多（正式的）AOP。
就个人而言，我会把模块放在第一位。
这样，如果您稍后将模块拆分为多个JAR / WAR文件（例如，分成单独的maven项目），则它们已经在正确的目录结构中，以便按模块拆分它们。
答案 3 :(得分：1)
我会逐层组织包层次，以便让您的工具工作。每个模块都会使用自己的源文件夹进入自己的项目。这为您的IDE和开发人员提供了简单的面向模块的分组，但您的运行时工具可以轻松实现面向层的分组
答案 4 :(得分：1)
我宁愿把模块放在首位，但在我看来，这样做你必须引用所有地方。这可能是开发人员之间混淆的原因。