关于 Java 后端开发规范 Or 个人习惯？谈谈你们的理解和现有项目的状况。

[ponder09]

这是我第一次在 V 站发帖，有点小激动啊！ 先自我介绍一下，一个 Java 后端开发人员，三年+经验。现在有几个日常开发中遇到的问题，因为 V 站的大厂大佬比较多，所以想跟大家请教请教，希望大家可以谈谈自己的看法。

问题 1 、在开发一个新功能时，我们定义好了具体的表模型，在定义 Controller 、Service 、Mapper 、...层的时候是怎么划分的。

1. 严格按照表模型的粒度来划分的。比如：user 表，就有 UserController 、UserService...
2. 是按照业务场景的粒度来划分的。比如：比如查询用户信息的业务场景（查询职务、职位、组织等等）需要四五张表才能支撑起来。定义一个统一的 UserDetailController 、UserDetailService...
3. 以上两种混合使用。怎么方便怎么来。

---

问题 2 、还是和 Service 和 Mapper 层有关，现有 AController 、AService 、AMapper 、BController 、BService 、BMapper 、...、ZMapper 。在注入相关对象的时候，有以下两种使用方式，你们使用哪种，或者有其他方式。

1. AController -> AService -> AMapper ，BController -> BService -> BMapper
2. AController -> BService -> CMapper ，BController -> AService -> CMapper

层级：就是问题一中两种划分粒度，第一种是按表模型，第二种是按业务场景。

第一种是严格注入，Controller 层只能注入本层级的 Service ，本层级的 Service 只能注入本层级的 Mapper ，本层级 Service “仅” 可以注入其他层级的 Service ，不能注入其他层级的 Mapper 。

第二种就是比较随意，Contorller 层可以注入非本层级的 Service ，Service 也可以注入非本层级的 Mapper 。

---

问题 3 、谈谈对单元测试的看法。

1. 业务场景太复杂，100 行的业务代码，可能要写 500 行的单测代码，要 Mock 一大堆东西，有些抵触，个人更偏向于自己写完代码，自己调用接口，修修补补。也有可能代码功力不够，方法拆的不够小，导致单测代码比较难写。也知道单测对系统稳定性、低级 Bug 的发现有立竿见影的效果。
2. 你的想法 /你们项目的做法。

---

先说我自己习惯的使用场景吧。以上问题都是选第一种，可能我有强迫症？或许有些矫情？

大家可以谈谈自己的习惯，和现有项目中的现状，让我学习学习[手动狗头]。

以上仅仅是本人看法，不喜轻喷。

[Terminator0826]

怎么舒服怎么快怎么来吧，老板不理解的

[aecra1]

1/2 你开始写得再好后面看的时候都觉得是屎山，如果不是那就是技术上没啥进步或者这个项目太稳定了
3 函数写小函数，多写注释，有代码 review ，不测试流水账函数，测试又臭又长的业务函数没人想搞

[optional]

按照 ddd 找聚合根的方法分 service

[itechify]

第一种太理想化了，少数业务需求才能单表 crud 。个人见解：业务的迭代，逻辑会越来越复杂，代码会越来越多。尽量保持一个类功能少一点，行数少一点，读起来也舒服点，这样也可以降低冲突概率，降低合并负担。

[ponder09]

@Terminator0826 哈哈 可以的

@optional 这样不会导致聚合的 service 最后太大吗。我现在是习惯把相关业务有关的 service 就放到具体和数据库表模型对应的 service 中，有点聚合根的意思，但是没有新建 controller 、service 做这些事情。

@aecra1 学到了 第三个问题，确实是我要改正加强的地方

@oneisall8955 可能我没有描述清楚，我们的业务肯定不是单表 crud ，肯定是有相互注入的，我的意思是不是要新建聚合的 service ，还是把相关逻辑放到具体表模型的业务类中。

[zoyua]

你应该是缺了一层，controller -> manager -> service -> mapper

[ponder09]

@zoyua #6 原文：“你应该是缺了一层，controller -> manager -> service -> mapper”
======
回复：那么 controller 和 manager 是聚合业务的吗，service 和 mapper 操作单表的？

[optional]

@wangxin3 写进去确实会很大，尝试过把一些操作拆出来放到 domain service ，domain service 本质上是 static method 集合（实际放 spring 还是 non static 只是没有外部依赖），只负责操作相关的 data model （因为不想搞 ddd 充血模型那一套，还是搞成类似扩展方法的形式），这样的好处是单元测试简单，按顺序加锁都不会有问题

[ponder09]

@zoyua #6 原文：“你应该是缺了一层，controller -> manager -> service -> mapper”
======
回复：刚查了下。阿里开发手册定义的 manager 层是介于 service 和 mapper 之间的。
Manager 层：通用业务处理层，它有如下特征：一是对第三方平台封装的层，预处理返回结果及转化异常信息；二是对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；三是与 DAO 层交互，对多个 DAO 的组合复用。

[amwyyyy]

我之前待过一家公司是有讲究的，要控制好分层和 service 的调用关系。不过现在都是微服务，单个应用业务不会太复杂也没有很多的类，就比较随意了。
单元测试作用挺大的，就是项目没给时间写，也不要求，所以我做过的项目 99%都没有写。