优点当然也是有的：

1. 可以练手，不然你下一份工作的简历怎么办？
2. 容器化管理起来确实容易，哪怕我就俩服务，用 k8s 也方便些，至于你说消耗的资源……那是老板的钱，又不是我的。
3. 战未来，万一火了呢？
4. 微服务不仅能拆分大型软件，还能方便拆分团队，如果一个项目有很多个组参与，使用微服务会比写成单体然后让大家工作在同一个仓库下容易些……同理，如果前提是没几个用户，进程内通信和跨进程通信相比那点优势也微不足道。至于额外的复杂度，k8s 也基本能解决，没几个用户的项目又能复杂到哪儿去呢？

额外建一张表存 B2 和对应的统计值，每次插入在同一个事务里往主表插入并让副表统计值+1 。

这个升华部分的批判毫无道理……就好像在批判 Java 这样有 GC 的语言让程序员的平均水平降低了一样……
事实上确实降低了，但它同时降低的还有这个行业的门槛，最终的结果是提高了整个行业的生产效率，而效率才是市场真正追求的东西。
至于顶尖人才变少，这个不知道有没有具体数据支撑？也许这些人的绝对数量并没有什么变化，给你这种感觉是因为他们占行业总人数的比例减少了。

需求简单的话，Ruby 的 RoR 或 Py 的 DRF 了解一下

都微服务了，要不整个 k8s 吧……也算 Go 技术栈，后面你说的这些需求甚至可能不怎么需要写代码就能解决了。

@ben548 呃，不需要的。虽然不知道你使用什么技术栈，但正常点的语言实现异步处理都不会很困难，无论你用线程协程还是其他进程（消息队列也属于跨进程异步）。

只能说明他们实现了同一组接口

fastapi / django

返回前用另外的线程/协程处理一下不就好了吗？还是说一个查询重到必须用消息队列？
并发问题要看具体需求，一般来说加锁就完事了。

你这个静态……指的是浏览器打开本机文件？还是要放在服务器上？

import _ "github.com/joho/godotenv/autoload"

用这个，最好结合 7 楼的做法

@tedding #25 已加，我的: blog.yeningxue.com

17 年就在写好强

加上了，我的: blog.yeningxue.com

https://github.com/laipz8200/gin-template

顺便贴一下自己的，这套我最近没怎么维护了，而且直接把领域相关的内容全放在一个包下面也不见得好（但至少不会在导入时遇到重名），仅供参考

1. ddd 没有明确代码结构，也不需要
2. go 语言写业务代码挺坐牢的，结构尽可能简单比较好
3. Java 那种组织代码的方式和 Go 导入包的方式有那么一点点冲突，写起来会不太舒服
4. 假设你使用 DDD 是为了处理大型项目，那我可以进一步假设这个大型项目会采用微服务，这种情况下代码里只需要一个聚合/服务就够了，外面加 1-N 个适配器

@tinytian 也有 Google 这种依赖 webview 做跨 App 登录的

分工带来的是效率提高，比如你有可能做到工作一整天不需要自己做饭也不需要出门找饭店，至于人的主观感受，应该不在这个发展考虑的范围内。

我个人的体验是 chatgpt 最好，bard 代码中不存在的库或方法最多，基本没法信任。

claude 可能介于两者之间，比较接近 chatgpt 。