通常认为 go 更适合写中间件,复杂业务开发还是交给 java 吧。
我们一直以来对处理软件开发的业务复杂性感兴趣,思考下来发现要处理好业务复杂性其实和用什么语言没什么关系,更为重要的是以下几点:
早期我们认为 DDD (领域驱动设计)是能比较好的解决问题的方法论,经过长期实践后我们发现 DDD 成功落地需要做很多减法,最后我们开始重新思考,抽象了Aggregate (聚合)、Repository (仓库)、Process (过程)的方法论。也用 go 实现了一套框架:https://github.com/framework-arp/ARP4G,之前 ARP 框架也用于生产了几个项目。
现在就是想看看大家的想法和疑问,帮助我们探索解决软件业务复杂性之道,也欢迎试着用用看和你们的 issues
1
wencan 2022-11-06 17:58:30 +08:00
怎么把复杂业务逻辑写好,似乎完全不被重视。还是第一次遇到同样在关注这个的朋友。
我设计和实现复杂的业务, 一部分是基于自己对 solid 的理解,具体还有待整理; 另一部分见: https://blog.wencan.org/2022/10/21/programming-thinking/ 最近,我也在开发一套开源组件库。不过依据我的编程思想,它必须是组件库,没有重复的轮子,地址为: https://github.com/wencan/fastrest 如果有兴趣进一步沟通:ZW1haWw6IHdlbmNhbkBmb3htYWlsLmNvbQ== |
2
BeijingBaby 2022-11-13 19:19:32 +08:00 via iPhone
看了一下就是典型的 service ,repo 模式,感觉比较常见吧,目前我们 dev.com.cn 后端是这个模式。
再扩展一下就是洋葱架构了。 |
3
securityCoding 2022-11-14 03:15:46 +08:00 via Android
我转 go 正好,其实没啥大的区别,比 spring 有意思一点,鹅厂内部新业务好多都是 go 了,框架工具集成都做得挺好
|
4
tikazyq 2022-11-14 09:45:27 +08:00
有意思,看起来跟 Sprint JPA 优点像了。不过好像还不完全,如果能有一个能高度抽象各种业务类的方式就更好了。目前来看,Go 跟其他框架来比写业务逻辑的问题,主要在于泛型的缺失,现在虽然有了,但还不清楚是否已经足够强大了
|
5
zhengchengdong OP @BeijingBaby 是的,现在看来就只有 service 和 repo 了,这样最简单最好理解。实际上我们是从多层结构退回来的,比如之前我们一直写两层 service ,差不多就是 DDD 的 domain service 和 app service 。实际操作下来 DDD 过多的概念导致只有极少数人能恰当运用,运用不当的情形比运用得当的多了太多。所以我们重新思考后认为 ARP 三个概念就够了,就一层 service ,service 就是一些 process 的集合,另外 repo 就是存放聚合的一个地方,所以从分层来看差不多就只有 service 和 repo ,且不会再扩展了
|
6
zhengchengdong OP @tikazyq 你提到的高度抽象各种业务类的方式,我估计你说的是 "业务复用",这是另外一个主题,不过和 ARP 确实也有关系。我们尝试过抽象出可复用的业务类,到了具体不同业务不可避免的会有个性需求,通常我们用 "插件" 的策略来处理个性需求,这种做法也很常见,就是在抽象的业务类里面组合了各个 "变化点" 的策略对象,这些个策略对象就是 "插件" 。比如我们游戏匹配的 Matcher 对象,不管什么游戏,他总是从匹配池捞上来所有匹配请求,然后按一定的规则,比如积分相近,进行分组,分组结果作为匹配结果,那么这个匹配规则就做成一个 "插件",其他部分都是不变的。实际实践当中我们发现,随着面对越来越多的游戏,总是有之前没有想到的变化点,比如有的游戏希望匹配不上的人要重回匹配池,那么我们就要加一个 "落选处理" 的插件。诸如此类,最终我们发现插件总是越加越多,更糟糕的是一个具有 10 个插件的业务类对某个具体业务来说可能只需要 4 、5 个插件,其他插件根本不关心,于是我们对于具体业务要写好多个他不关心的业务插件的 "哑" 实现。后来,我们重新思考了 "业务组合的方式",从 "抽象业务类组合插件" 变成了 "过程 append 过程",这个 "过程" 就是 ARP 的 P ,然后基于 P 我们提了一个新的概念叫 AP (抽象过程),后来我们都是通过抽象过程来做业务抽象。那么我们发的这个 ARP 框架对于业务抽象是起到关键支撑作用的,具体欢迎关注后续的开源工程。
|
7
YuuuuuuH 2022-11-23 20:11:27 +08:00
@zhengchengdong #5 把两个 service 合成一个 service 大概率导致领域逻辑外溢,领域模型逐渐贫血,最后又变成事务脚本。
|
8
zhengchengdong OP @YuuuuuuH #7 估计外溢说的是领域逻辑从 domain object 溢到了 service ?这一点是这样的,实践下来发现很难把所有的业务逻辑都封装在 domain object ,很多业务是几个对象之间协作完成的,硬要把他们塞进 domain object 有人就会生生造出 XXXManager 这样的伪 domain object ,其实 XXXManager 就是个 domain service 了,所以我们和 DDD 在 “service 也属于领域逻辑” 这一点上看法是相同的,所以 service 里面有领域业务算不上外溢。后来我们改进的只是把两层 service 合并成了一层,原因是发现有很多人写 service 出现了心智负担: “两个 service 都要写吗?外面那个就是代理了一下啥也没有啊?那如果只写一个的话到底是只写 domain service 还是只写 app service ?什么时候要写两个?什么时候只写一个?”,所以就一个 service ,类似于后来 clean architecture 的设计,同时我们当时并不知道 clean architecture ,说明我们同时认识到了只写一层 service 更合适些。
|