问题描述
我习惯把一切都放在包是这样的：
I used to put everything in packages like this:
com.company.app.module1
com.company.app.module2
但它使基于软件包AOP切入点困难，导致需要一个IDE，使感大包。
But it has made package-based AOP pointcuts difficult, and resulted in huge packages that need an IDE to make sense of.
所以，现在我意识到我需要一个更深层次的封装结构，但我不断地撕裂。给模块preference，也是这样吗？
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
或给予层preference，也是这样吗？
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?
推荐答案
模块一。
我有一个项目，最初层，第一，但它变得太笨重阅读和维护，因此，我们重构了。它使用AOP，以及 - 没有任何问题。我们只是用 .. 在包定义的中间（我们使用了AspectJ的语法的Spring AOP）。下面是它的样子：
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..*.*(..))
这同时匹配 modules.module1.service 和 modules.module2.service
这篇关于模块VS在Java包层结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！