对后端分层的一些疑问

先建必须的 Controller 。

Service Mapper 大部分情况下除了能起到增加复杂性的作用外，都是次要的。

所以简单的代码塞到 Controller 一个文件里面就好。

复杂度达到了有多个 Controller 公用的代码，扔到 Service 里面复用。

Mapper 垃圾，扔掉

楼主应该指的是 按功能模块去组织代码
这边一般认为小项目，功能模块不多的情况下按照 代码类型分包放
功能模块多的时候 按照功能模块来分包 这样独立一些 多人维护的时候也不容易出问题

我们的 controller 一般按照实体类分。。

完全可以，我就是这样做。比如登录的，就把 controller service mapper bean 都放在 login 包下面

业务复杂度是代码复杂的根本原因，你找的时间长是因为你不熟悉这个类的各个层。
按照功能来分包、拆封微服务都是为了切割业务，让各个业务之间解耦，这样新人需要熟悉的业务就更少，自然熟悉业务的时间更短。

假如新人觉得很难上手，没人愿意接，都跑路了，说明该重构了

一个 mapper 可能被多个 service 调用，一个 service 可能被多个 controller 调用，我觉得按照功能把各个层的类放在一个包里面并不是一个好的选择，复杂的业务下可能会让类更加混乱

idea 里面 shift 按两次，可以快速找文件。我们公司有些项目的代码是一个类一个包。。。我的猜想这样分层可能为了 aop 的效果更加精确一点？？？

简单的话完全可以，分层只是为了工程化，其他的没什么。

1.缘起 J2EE 时期的设计模式
2.按照不同包来组织是一种设计哲学，“约定优于配置”，这种写法无时无刻在提醒开发者注意降低业务间的耦合性
3.你说的可以的，只是没遵守 JavaEE 界的工程约定。副作用也会有，一两个人的小项目倒是无所谓，但经常迭代的话随时间推移不同参与者写着写着代码就变得难以阅读了

这里有一个群哈，主要是学生交流 java 前端，有兴趣的可以进来大家一起交流，也可以推荐同学哈。里面还是有热心的大牛的
https://i.loli.net/2020/11/02/rTfPHkw8iuoRc1e.png

框架就是让你按照他的代码约定格式做业务

简单的 CRUD 还好，不同功能依赖时候还是由这个问题。记得 JEESITE 就是这么设计的。
熟悉了现有代码以后，IDEA 类搜索很快。

我觉得楼主你想法其实是对的，现在这样按层工程分包方式就是不对的。
从业务上讲，同一领域内的对象应当聚合在一起，这也是为了把领域内的知识都限制在包内，而不是散落在项目的角落里。
Node.js 在 Github 上 star 最多的 Best Practices 明确表明应当按业务分包。
为了照顾没有团队规范的多人开发，而抛弃正确的项目结构，我认为是本末倒置了。

是的，应该按照业务分包管理的。

本来就可以，而且有些地方，比如 go 官方就提倡这么搞
现在这种分层是加 J2ee 那一套，属于历史遗留问题。当年大量传统企业涉足信息技术(其实就是找外包做一个 ERP 系统)，

本来就可以，而且有些地方，比如 go 官方就提倡这么搞
现在这种分层是 J2ee 那一套，属于历史遗留问题。
当年大量传统企业开始搞信息化(其实就是找外包做一个 ERP 系统)，一方面当时开源不发达用 C/C++撸 web 比较蛋疼，另一方面传统企业也不愿意出太多钱请不起 C++大佬。所以 javaer 就靠着量足价优承包了几乎所有传统企事业和机关单位的 It 外包，用友金蝶就是代表。把 J2EE 这一套广泛传播出去了，
然后大家发现这一套也确实好用，不管你再菜，照着一大套条条框框来，总错不到哪里去，应付传统行业的甲方爸爸完全没问题，就这样沿用至今来。

django 也是这样的吧

这还简单，才三层，出来混才发现，不止，manager 层见过没，一开始简简单单 controller service dao model 就搞定了？
DO DTO VO，头都大，怀念以前 CRUD 的日子，一去不复返

@BoarBoar 话说 go 官方提倡这么搞有什么依据吗，比较好奇