Java中包同时包含类与子包是否属于不良实践？

其实这不是绝对的不良实践，更多取决于你的代码组织逻辑和团队里的约定。咱们先拿你给出的示例来拆解分析：

com/
 domain/
  SomeClass.java
  AnotherClass.java
  model/
   Model1.java
   Model2.java
  somePackage/
   SomePackageClass.java

什么时候这种结构是合理的？ #

• 如果SomeClass和AnotherClass是domain包的核心抽象或入口类——比如统管整个领域逻辑的DomainFacade、DomainService，或者是对外暴露的API接口，放在子包外面是完全没问题的。它们相当于domain包的"门面"，让其他模块不用深入到子包就能调用核心功能，反而符合迪米特法则（最少知道原则）。
• 当顶层类数量极少（比如2-3个），且职责和子包明确区分开时，这种结构不会造成混乱，反而能让核心逻辑一目了然。

什么时候这种结构会变成不良实践？ #

• 如果顶层类和子包内的类职责边界模糊——比如SomeClass明明是和model相关的实体类，却随便放在了domain顶层，那时间久了，新成员会搞不清新类该放顶层还是子包，包结构的分类意义就彻底丧失了。
• 当顶层类数量越来越多，逐渐堆成"大杂烩"时，整个包的可读性和可维护性会急剧下降，这时候就必须重构了。

关于另一种方案：把顶层类放进第三个子包 #

如果把SomeClass和AnotherClass放进domain/core或者domain/api这类子包，优势是包结构更规整、职责划分更绝对明确，所有类都归属于某个细分的子包，不会出现"游离"的顶层类。但这也不是必须的：

• 如果你的domain顶层类确实是核心入口，强行塞进子包反而会增加调用层级，让其他模块需要多写一层包路径才能引用，有点画蛇添足。
• 只有当顶层类数量开始膨胀、职责开始混杂时，这种规整化的结构才更有意义。

总结几个判断原则 #

• 优先保证职责单一：同一个包下的类和子包必须围绕同一业务或技术职责展开；
• 保持可维护性：让新成员能快速判断新类该放哪里，不用靠猜；
• 遵循团队约定：如果团队已经有统一的包结构规范，那就跟着来——代码的一致性比"最优结构"更重要。

内容的提问来源于stack exchange，提问作者iddqd