@kernelpig 呕吼,我是因为一个 state server, go 上的 gc 抖的太厉害才用 rust 的
是挺陡峭的,我看了下 commit, 距离第一行代码正好一个月.

看你要干什么

是不是搞混了一个概念:

制定标准的意义就是为了更清晰不是么.

如果 x 公司的标准非外部,爱咋弄咋弄~ 黑话也是话.

但如果跨出门了.有个更标准的规则遵循.即说普通伐更省事

clone discord ~

之前拆了.现在大多合成一个了.而且啥 dto,啥分层,啥 repo, 啥啥啥的都没了.现在单元测试,脚本一个文件模块梭哈
要说拆出来的服务.就是各方依赖.一搭眼就看来的基础服务.比如权限服务,状态服务之类的.没啥理由为什么拆.

感觉说成宏(微)服务. 大家更好明白点

1. A-> state service -> B (服务拆分)
2. A -> MQ -> B 消息队列广播 另外一种: A-> Route GRPC -> B 私信
涉及的东西有点多.甚至都不知道在哪开始聊

结婚, 108 -> 170

有没有可能流程是 使用 stream, send -> limit buffer -> rev 呢?

话说回来.我主要是看重检索能力.

不知道有没有人和我一样
我一般都是用 slack 之类的扔到某个 channel. 类似 wechat 的文件传输助手
主力 mac 上用的 devonthink. 做 rss, 我也懒得手动挑拣同步

- Alfred
- DEVONThink
- Surge
- Dash
- Eagle
- Sip
- Moom

ps:有些软件.被我赶上终身转订阅的许多.恶意满满~
大版本重新计费.在支持正版的路上.我 mac 还 15 的.都够换好几代了.
热情已经耗尽.

https://go.dev/doc/effective_go Interface checks

3389 啊.犹记得当年扫这个端口不小心碰到大爷大妈正在远程相亲.

咦.没想到这么靠前,竟然看到想看到的答案. @thinkershare
这位兄弟说的是应该思考实践过的.
有些人认为 ddd 先行,在我看来并不是的.
和 mvc 这种并行,是错误的观念.他只是一个辅助分支的模式.
他是一个在架构设计完整下的补充.也就是说他不会带来一个完整的架构.
不要沉迷这个东西.从另一个观点来说,一个你搜遍全网也没获得完整知识架构情况下,
只能通过只言片语靠硬思考的所谓概念.自信点,这货并不那么靠谱.

- 有些人看眼文档就打开了记忆宫殿
- 有些人看了眼文档却有了我是谁我在哪的怀疑

自己写的代码一个星期都"卧槽".

记不住这些. 挺正常的.

微信不值得你折腾

@HeyHudy @redtech 对标话,应该是 slack,discord 那种开放程度特别高的应用层.

我们大概也许应该需要一个类 unix 的开放性应用吧.鬼知道真正的形态是啥.

这也是我的目标.

如果可以的话,这样的摸鱼可以吧?

哦哦哦懂了. 有没有想换个思路. 让他们忙起来.比如搞组队, 搞开发,就像我的世界那种,一切功能一起搞建设.当然基础服务之上.
说人话就是"人人都是产品经理".