java 软件包 功能_（Java）软件包组织有最佳实践吗？

我更喜欢图层之前的要素，但我想这取决于您的项目。考虑一下你的力量：

依赖性

尝试最小化程序包的依赖性，尤其是功能之间的依赖性。如有必要，提取API。

团队组织

在某些组织中，团队在要素上工作，而在另一些层次中。这会影响代码的组织方式，使用代码形式化API或鼓励合作。

部署和版本控制

将所有内容放到模块中可使部署和版本控制更简单，但错误修复更困难。拆分事物可以实现更好的控制，可伸缩性和可用性。

响应变更

井井有条的代码要比大团糟容易得多。

大小(人员和代码行)

越大，则需要越正式/标准化。

重要性/质量

一些代码比其他代码更重要。API应该比实施更稳定。因此，需要将其清楚地分开。

抽象级别和入口点

外部人员应该有可能知道代码的含义，以及从查看包树的位置开始阅读。

例：

com/company/module

+ feature1/

- MainClass          // The entry point for exploring

+ api/               // Public interface, used by other features

+ domain/

- AggregateRoot

+ api/             // Internal API, complements the public, used by web

+ impl/

+ persistence/

+ web/               // presentation layer

+ services/          // Rest or other remote API

+ support/

+ feature2/

+ support/             // Any support or utils used by more than on feature

+ io

+ config

+ persistence

+ web

这只是一个例子。这是很正式的。例如，它为feature1定义了2个接口。通常这不是必需的，但是如果不同的人使用不同的方法可能是个好主意。您可以让内部API扩展公共范围。

我不喜欢'impl'或'support'名称，但它们有助于将次要的内容与重要的内容(域和API)分开。说到命名，我喜欢尽可能具体。如果您有一个名为“ utils”的包，其中包含20个类，请StringUtils转到support / string，HttpUtilsupport / http等。