Java 包结构中的模块与层 [英] Modules vs Layers in Java package structure

问题描述

我曾经把所有东西都放在这样的包里:

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.

所以现在我意识到我需要一个更深的包结构，但我经常被撕裂.给模块偏好，像这样?

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

各有利弊?

推荐答案

模块优先.

我有一个最初是层优先的项目，但它变得过于庞大而无法阅读和维护，因此我们对其进行了重构.它也使用了 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

这篇关于Java 包结构中的模块与层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！