Java 工程 要不要把包分的特别细？
1、项目之初，功能少、实现简单，只需要简单的分层，这个是最好的一个方式，如 src dao service controller dto entity other 2、需求迭代后,业务复杂了，同一个包下的Java类太多了，此时需要按照模块进行划分包， 具体的实现，在原来的分层基础上，按照模块进行拆子包，如 ： src dao goods member service goods member business goods member controller -- 暴露门面可以在一起 rpc的 facade 也是如此 dto goods member entity goods member other convert utils 3、除了完成步2阶段的事情，还有做一些约定，此时来提出这个约定是非常好的时期 其实在1阶段时候，也是可以提出的，也是一个不错的时机，但从0-1的阶段如果约束多，对整体进度有影响， 所以，我个人意见是在2阶段提出约束，是最佳时期， 具体约束如下： 1、service 层中 平级之间不能互相调用， 如果想要在A.service 中调用 B.servie 中的function ，需要上移一层 业务聚合层 -- 也建议采用下沉的方式实现，service 就是处理业务的 , 把其中的业务逻辑下沉一层 处理方式思想都一样，不要出现网站调用 2、分层后，vo的传输，转换需要加进来，1阶段一个对象从入口干到持久化，赶进度是可以接受的， 但业务复杂，分层加入之后，必须摒弃省事的做法，转换是必须的。 3、清晰的注释，entity 定义的、枚举类、接口定义、一级实现逻辑、业务约定等等 要在代码中提现出来 4、文档，此时必须沉淀起来，包括但不仅限于、接口文档、设计文档、prd文档、多种图
4、刚刚踏入2阶段，需求迭代，尤其是出现周期很短、频次很高、甚至出现并行需求情况， 到此阶段是需要小心处理的，到此阶段项目应该有一年以上的周期了 版本概念要提出 1、git（也有别的管理方式）分支管理开始复杂 2、prd 需求 版本错乱，常常出现临时插入个紧急需求， 版本管理只能是对应具体的场景来说，prd 版本， git 版本， 分支维度 3、人员的稳定开始冒尖了，开始有老员工离职、新鲜血液进来 5、已经迭代了很多需求，性能、系统复杂开始出现， 性能调优，拆模块、拆包、已经不能很高的解决，要开始拆业务，拆子工程了、拆微服务， 这时，如果分包的事情做了很好，此时耦合是很小的，划分微服务是非常方便的， 如果做的不好，表、代码，不是很容易摘出来，最差情况，出现大的重构了，基本是重新研发，按照微服务模式重新研发，如果做的好，很简单就能把业务和代码摘出来。
