我的问题是实现高内聚性，但我认为下一个例子促进了低内聚性和高耦合性，我想有人来解释一下，如果是这样的话，我说的是在我工作过的的任何项目中都很常见的包策略
com.example.dao.reservation
ReservationDAO
ReservationDAOImpl
com.example.dto.reservation
ReservationDTO
com.example.entity.reservation
ReservationEntity
这个例子通常带有一些坏习惯，我们有接口和公共实现，我们还需要将字段暴露给get和set以管理State(例如，这有时会导致通过验证getter的无效性来管理其他类中的State)，而且我们不能将相关的东西放在一起。
我认为，如果我们采用以下一揽子策略，这将是促进高内聚性和低耦合性的更好方法：
com.example.reservation
ReservationDAO
ReservationDAOImpl
ReservationDTO
ReservationEntity
在第二种方法中，我们可以对属性、方法、构造函数等进行包访问
没有标准的方法来组织包，这取决于团队的偏好。
就我个人而言，第一个组织似乎有太多的包，而第二个组织似乎更容易理解。当按功能而不是抽象功能组织时，更容易理解项目(例如"保留"而不是"dao")。当我看到一个只有一两个文件的包时，这表明包可能太紧了。另一方面，当一个包包含超过20个文件(这里是任意数)时，它可能是重构成更小包的候选者。
关于实体类的一个注意事项：如果您使用Hibernate反向工程从DB构建实体类，最好将它们保存在一个单独的目录中，如果需要，可以删除(因为这些是自动生成的文件)。这个目录通常可以有很多文件，这是可以的，因为它映射到整个数据库。在这种情况下，请按抽象函数(实体)而不是功能来组织此文件夹。
我知道你使用的是Java，但在使用Angular一段时间后，我开始了解如何应用Angular Style Guide的建议：
"当组件有多个附带文件(.ts、.html、.css和.spec)。">
https://angular.io/guide/styleguide#style-04-06
上面的"按组件组织"建议与您的"按功能组织"示例("保留")类似。
"请创建以其所代表的功能区域命名的文件夹。">
"为什么？开发人员可以找到代码并确定每个文件所代表的内容一眼望去。结构尽可能平坦，没有重复或多余的名字。
为什么？LIFT指南已全部涵盖。
为什么？帮助减少应用程序在组织过程中变得混乱内容，并使其与LIFT指南保持一致。
为什么？当有很多文件时，例如10+，定位它们是使用一致的文件夹结构更容易，在平面中更难结构">
https://angular.io/guide/styleguide#style-04-07
组织包没有被广泛接受的"最佳实践"。我目前倾向于按照单一责任原则来做这件事。
根据SRP，您编写的每个组件(包、类、模块等)都应该满足外部需求或其他组件实现的需求。由于每个组件最多有一个"boss"组件，组件->boss链接形成一个树。
这个SRP树是任何软件设计中极其重要的一部分，但它不会出现在标准图中。没有标准的UML箭头表示"需求源"，标准图中也没有任何内容可以表明您在设计中遵循了SRP。
因此，我使用包结构来同时记录项目中做出的SRP决策，并确保SRP得到实际遵守：
- 顶级软件包满足外部需求
- 子包满足其父包实现的要求
这在代码中也能很好地工作，并且更容易地确定哪些内容属于哪个包，因为它不再只是对模糊相关的内容进行分组。
为了回答您关于预订层次结构的具体问题，我想问您："是否有预订组件"？正常的答案是，如果你遵循的是清晰的/洋葱形/六边形等。架构是"不"的。
您可能有一个数据访问层，数据访问组件应该是其中的一部分。
您可能有一个API层，数据传输组件应该是其中的一部分。
所以，我更喜欢dto.*、dao.*等的层次结构，但我真的更喜欢您的包包含系统组件，如com.example.api.dto.ReservationDTO，因为您的DTO没有外部要求。