我的问题是关于实现高凝聚力，但是我认为下一个示例将促进低凝聚力和高耦合，如果有这种情况，我会有人向我解释，我正在谈论在任何项目中都很常见的打包策略我曾经工作过
com.example.dao.reservation
ReservationDAO
ReservationDAOImpl
com.example.dto.reservation
ReservationDTO
com.example.entity.reservation
ReservationEntity
此示例通常带有一些不良习惯，我们既有接口又有公共的实现，我们还需要将字段暴露给get和set以便管理国家（并且这种思想导致通过其他方式管理其他类别的国家例如，验证一个吸气剂是否为空），我们也不能将相关的东西放在一起
我认为如果采用这种打包策略，将有更好的方法来促进高内聚和低耦合
com.example.reservation
ReservationDAO
ReservationDAOImpl
ReservationDTO
ReservationEntity
在第二种方法中，我们可以访问属性，方法，构造函数等包
没有一种标准的方式来组织您的包裹，这取决于您团队的偏好。
就个人而言，第一个组织似乎包太多，而第二个组织似乎更容易理解。当按功能而非抽象功能进行组织时，更容易理解项目（例如，与“ dao”相对的“ reservation”）。当我看到一个包装中只有一个或两个文件的包装时，说明包装可能太紧了。另一方面，当一个软件包包含20个以上的文件（此处为任意数）时，则可以将其重构为较小的软件包。
有关实体类的注意事项：如果您使用Hibernate逆向工程从数据库中构建实体类，则最好将它们保存在单独的目录中，该目录在必要时可以删除（因为这些是自动生成的文件）。该目录通常可以包含许多文件，因为它映射到整个数据库，所以可以。在这种情况下，请通过抽象功能（实体）而不是功能来组织此文件夹。
我知道您使用的是Java，但是在使用Angular一段时间之后，我来看看如何应用Angular样式指南的建议：
“考虑在具有多个组件时为该组件创建一个文件夹随附文件（.ts，.html，.css和.spec）。“
https://angular.io/guide/styleguide#style-04-06
以上“按组件组织”建议类似于您的按功能组织示例（“预订”）。
“创建以它们代表的特征区域命名的文件夹。”
“为什么？开发人员可以找到代码并确定每个文件代表什么乍看上去。结构尽可能平坦，没有任何结构重复或重复的名称。
为什么？ LIFT指南均已涵盖。
为什么？帮助减少应用程序因组织而变得混乱内容并使其与LIFT指南保持一致。
为什么？当文件很多（例如10个以上）时，找到它们是具有一致的文件夹结构更容易，而在平面中则更困难结构。”
没有被广泛接受的用于组织软件包的“最佳实践”。我目前的偏好是按照单一责任原则进行操作。
在SRP之后，您编写的每个组件（包，类，模块等）都应满足一个外部要求或一个其他组件实现的要求。由于每个组件最多具有一个“老板”组件，所以component-> boss链接形成一棵树。
此SRP树在任何软件设计中都是极为重要的部分，但未在标准图中显示。没有标准的UML箭头表示“需求来源”，并且标准图中没有任何内容甚至可以表明您在设计中遵循了SRP。
因此，我使用包结构来同时记录项目中制定的SRP决定，并确保实际上遵循SRP：
这在代码中也非常有效，并且使找出哪个包中的包变得容易得多，因为它不再只是将模糊的相关内容分组。
要回答有关预订等级的具体问题，我会问你：“是否有预订部分”？正常答案（如果您遵循透明/洋葱/六边形/等）。建筑是“否”。
您可能有一个数据访问层，并且数据访问组件应该是其中的一部分。
您可能有一个API层，并且数据传输组件应该是其中的一部分。
所以，我更喜欢您的带有dto.* dao.*等的层次结构，但是我真的希望您的软件包包含系统的完整组件，例如com.example.api.dto.ReservationDTO