感觉很有道理 顶

如果这么容易，那写好设计文档代码都可以蒙出来了。。。

你这里只是 Controller 和 Dao，中间的 Service 才是复杂和精髓之处呀。

可知道里面有多少中间件？缓存怎么设计的？并发怎么设计的？队列怎么设计的？资损防控怎么设计的？安全怎么设计的？

估计楼主的前提就是深谙业务逻辑，像下面这种东西都已经了然于胸的

越复杂的 service 逻辑，说明业务代码或设计越烂。好的架构设计和规范，会让代码逻辑 清晰简洁

1、大致去反向推测，相当于 如果我自己去实现，要不要加缓存提高响应速度和性能，要不要使用消息系统提高吞吐量和解耦...
2、当然，具体的细节要看实际业务需求以及技术实现方案
3、好的测试必须熟悉业务逻辑和技术实现逻辑，不然测试的深度和广度没法保障

个人觉得，复杂逻辑和清晰的代码逻辑，两者不一定冲突？比如通过设计模式，能简化很多复杂问题的代码处理逻辑写法。

主要是觉得正文说得有点太绝对，特别是 “拿到数据库表结构，大致上就知道是怎么做的了”。一方面，一样的接口和数据库，资深的人会考虑幂等、补偿、熔断等多种场景的处理，普通人去 yy 可能就只能想到最直白简单的逻辑；另一方面，系统输入并不只有接口，输出也并不只有数据库。

举个例子，登录接口（login，入参为用户名和密码，返回登录结果）+ 用户表（存储用户 id、用户名以及密码），实现登录功能。
最直白的实现：直接给 dao 层执行一个数据库 sql，select user_id from user where username = #{username} and password = #{password} ，找得到就成功，找不到就失败。
但实际情况，安全因素需要密码加盐、加密存储、限制失败频率、账号多处登录互踢等；性能因素需要加缓存（随之带来各种为保障数据一致性问题加入的逻辑）、和写接口（如改密码）并发加锁、营销活动引起大流量时自动排队、限流乃至熔断等。这些并不一定只通过接口清单和数据库就能 “大致知道”，因为不属于这两个部分要考虑的点。虽然看起来是细节，但根据业务场景这些很可能都是必须要考虑且实现的项。

回归正题，主要还是觉得正文的说法有点太简单和绝对了，也缺少详细的论证例子，缺乏对代码逻辑的敬畏，所以看完觉得不大能认可。