go 写业务，也可以很简单

[zhengchengdong]

通常认为 go 更适合写中间件，复杂业务开发还是交给 java 吧。

我们一直以来对处理软件开发的业务复杂性感兴趣，思考下来发现要处理好业务复杂性其实和用什么语言没什么关系，更为重要的是以下几点：

• 要做到业务代码和技术代码分离，业务代码可以完全剥离技术代码单独测试
• 以实体（对应不同的语言可能为对象，结构体等）为最小操作单位，一个业务，要么整个实体的各个属性都参与进来，要么都不参与
• 编写业务代码不能有技术心智负担，比如写一个库存扣减，不能让人担心并发操作会不会扣成负数

早期我们认为 DDD （领域驱动设计）是能比较好的解决问题的方法论，经过长期实践后我们发现 DDD 成功落地需要做很多减法，最后我们开始重新思考，抽象了Aggregate （聚合）、Repository （仓库）、Process （过程）的方法论。也用 go 实现了一套框架：https://github.com/framework-arp/ARP4G，之前 ARP 框架也用于生产了几个项目。

现在就是想看看大家的想法和疑问，帮助我们探索解决软件业务复杂性之道，也欢迎试着用用看和你们的 issues

[wencan]

怎么把复杂业务逻辑写好，似乎完全不被重视。还是第一次遇到同样在关注这个的朋友。
我设计和实现复杂的业务，
一部分是基于自己对 solid 的理解，具体还有待整理；
另一部分见： https://blog.wencan.org/2022/10/21/programming-thinking/
最近，我也在开发一套开源组件库。不过依据我的编程思想，它必须是组件库，没有重复的轮子，地址为： https://github.com/wencan/fastrest
如果有兴趣进一步沟通：ZW1haWw6IHdlbmNhbkBmb3htYWlsLmNvbQ==

[BeijingBaby]

看了一下就是典型的 service ，repo 模式，感觉比较常见吧，目前我们 dev.com.cn 后端是这个模式。
再扩展一下就是洋葱架构了。

[securityCoding]

我转 go 正好，其实没啥大的区别，比 spring 有意思一点，鹅厂内部新业务好多都是 go 了，框架工具集成都做得挺好

[tikazyq]

有意思，看起来跟 Sprint JPA 优点像了。不过好像还不完全，如果能有一个能高度抽象各种业务类的方式就更好了。目前来看，Go 跟其他框架来比写业务逻辑的问题，主要在于泛型的缺失，现在虽然有了，但还不清楚是否已经足够强大了

[zhengchengdong]

@BeijingBaby 是的，现在看来就只有 service 和 repo 了，这样最简单最好理解。实际上我们是从多层结构退回来的，比如之前我们一直写两层 service ，差不多就是 DDD 的 domain service 和 app service 。实际操作下来 DDD 过多的概念导致只有极少数人能恰当运用，运用不当的情形比运用得当的多了太多。所以我们重新思考后认为 ARP 三个概念就够了，就一层 service ，service 就是一些 process 的集合，另外 repo 就是存放聚合的一个地方，所以从分层来看差不多就只有 service 和 repo ，且不会再扩展了

[zhengchengdong]

@tikazyq 你提到的高度抽象各种业务类的方式，我估计你说的是 "业务复用"，这是另外一个主题，不过和 ARP 确实也有关系。我们尝试过抽象出可复用的业务类，到了具体不同业务不可避免的会有个性需求，通常我们用 "插件" 的策略来处理个性需求，这种做法也很常见，就是在抽象的业务类里面组合了各个 "变化点" 的策略对象，这些个策略对象就是 "插件" 。比如我们游戏匹配的 Matcher 对象，不管什么游戏，他总是从匹配池捞上来所有匹配请求，然后按一定的规则，比如积分相近，进行分组，分组结果作为匹配结果，那么这个匹配规则就做成一个 "插件"，其他部分都是不变的。实际实践当中我们发现，随着面对越来越多的游戏，总是有之前没有想到的变化点，比如有的游戏希望匹配不上的人要重回匹配池，那么我们就要加一个 "落选处理" 的插件。诸如此类，最终我们发现插件总是越加越多，更糟糕的是一个具有 10 个插件的业务类对某个具体业务来说可能只需要 4 、5 个插件，其他插件根本不关心，于是我们对于具体业务要写好多个他不关心的业务插件的 "哑" 实现。后来，我们重新思考了 "业务组合的方式"，从 "抽象业务类组合插件" 变成了 "过程 append 过程"，这个 "过程" 就是 ARP 的 P ，然后基于 P 我们提了一个新的概念叫 AP (抽象过程)，后来我们都是通过抽象过程来做业务抽象。那么我们发的这个 ARP 框架对于业务抽象是起到关键支撑作用的，具体欢迎关注后续的开源工程。

[YuuuuuuH]

@zhengchengdong #5 把两个 service 合成一个 service 大概率导致领域逻辑外溢，领域模型逐渐贫血，最后又变成事务脚本。

[zhengchengdong]

@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 更合适些。