Golang Go语言写业务，也可以很简单
通常认为 go 更适合写中间件，复杂业务开发还是交给 java 吧。
我们一直以来对处理软件开发的业务复杂性感兴趣，思考下来发现要处理好业务复杂性其实和用什么语言没什么关系，更为重要的是以下几点：
- 要做到业务代码和技术代码分离，业务代码可以完全剥离技术代码单独测试
- 以实体（对应不同的语言可能为对象，结构体等）为最小操作单位，一个业务，要么整个实体的各个属性都参与进来，要么都不参与
- 编写业务代码不能有技术心智负担，比如写一个库存扣减，不能让人担心并发操作会不会扣成负数
早期我们认为 DDD （领域驱动设计）是能比较好的解决问题的方法论，经过长期实践后我们发现 DDD 成功落地需要做很多减法，最后我们开始重新思考，抽象了Aggregate （聚合）、Repository （仓库）、Process （过程）的方法论。也用 go 实现了一套框架：https://github.com/framework-arp/ARP4G，之前 ARP 框架也用于生产了几个项目。
现在就是想看看大家的想法和疑问，帮助我们探索解决软件业务复杂性之道，也欢迎试着用用看和你们的 issues
Golang Go语言写业务，也可以很简单
更多关于Golang Go语言写业务，也可以很简单的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
怎么把复杂业务逻辑写好，似乎完全不被重视。还是第一次遇到同样在关注这个的朋友。
我设计和实现复杂的业务，
一部分是基于自己对 solid 的理解，具体还有待整理；
另一部分见： https://blog.wencan.org/2022/10/21/programming-thinking/
最近，我也在开发一套开源组件库。不过依据我的编程思想，它必须是组件库，没有重复的轮子，地址为： https://github.com/wencan/fastrest
如果有兴趣进一步沟通：ZW1haWw6IHdlbmNhbkBmb3htYWlsLmNvbQ==
更多关于Golang Go语言写业务，也可以很简单的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
有意思，看起来跟 Sprint JPA 优点像了。不过好像还不完全，如果能有一个能高度抽象各种业务类的方式就更好了。目前来看，Go 跟其他框架来比写业务逻辑的问题，主要在于泛型的缺失，现在虽然有了，但还不清楚是否已经足够强大了
是的，现在看来就只有 service 和 repo 了，这样最简单最好理解。实际上我们是从多层结构退回来的，比如之前我们一直写两层 service ，差不多就是 DDD 的 domain service 和 app service 。实际操作下来 DDD 过多的概念导致只有极少数人能恰当运用，运用不当的情形比运用得当的多了太多。所以我们重新思考后认为 ARP 三个概念就够了，就一层 service ，service 就是一些 process 的集合，另外 repo 就是存放聚合的一个地方，所以从分层来看差不多就只有 service 和 repo ，且不会再扩展了
你提到的高度抽象各种业务类的方式，我估计你说的是 “业务复用”，这是另外一个主题，不过和 ARP 确实也有关系。我们尝试过抽象出可复用的业务类，到了具体不同业务不可避免的会有个性需求，通常我们用 “插件” 的策略来处理个性需求，这种做法也很常见，就是在抽象的业务类里面组合了各个 “变化点” 的策略对象，这些个策略对象就是 “插件” 。比如我们游戏匹配的 Matcher 对象，不管什么游戏，他总是从匹配池捞上来所有匹配请求，然后按一定的规则，比如积分相近，进行分组，分组结果作为匹配结果，那么这个匹配规则就做成一个 “插件”，其他部分都是不变的。实际实践当中我们发现，随着面对越来越多的游戏，总是有之前没有想到的变化点，比如有的游戏希望匹配不上的人要重回匹配池，那么我们就要加一个 “落选处理” 的插件。诸如此类，最终我们发现插件总是越加越多，更糟糕的是一个具有 10 个插件的业务类对某个具体业务来说可能只需要 4 、5 个插件，其他插件根本不关心，于是我们对于具体业务要写好多个他不关心的业务插件的 “哑” 实现。后来，我们重新思考了 “业务组合的方式”，从 “抽象业务类组合插件” 变成了 “过程 append 过程”，这个 “过程” 就是 ARP 的 P ，然后基于 P 我们提了一个新的概念叫 AP (抽象过程)，后来我们都是通过抽象过程来做业务抽象。那么我们发的这个 ARP 框架对于业务抽象是起到关键支撑作用的，具体欢迎关注后续的开源工程。
#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 更合适些。
在IT领域，Go语言（Golang）凭借其简洁、高效和并发处理的优势，已经成为许多开发者写业务逻辑的首选。确实，用Go语言写业务可以很简单，这得益于其设计哲学和一系列实用的特性。
Go语言的内建并发支持，通过goroutines和channels，让开发者能够轻松地编写出高并发的业务代码。相比传统的多线程编程，Go语言的并发模型更加直观和易于管理，减少了因并发带来的复杂性和潜在错误。
此外，Go语言的语法简洁明了，减少了冗余和复杂性。它没有复杂的继承和多态机制，而是提倡组合和接口的使用，这使得代码更加清晰和易于维护。对于业务逻辑来说，这种简洁性尤为重要，因为它能让开发者更快地理解和修改代码。
Go语言还拥有一个丰富的标准库和活跃的第三方库生态系统，提供了大量的实用工具和库来处理各种业务场景。无论是网络编程、数据库操作还是文件处理，Go语言都能提供高效且易于使用的解决方案。
总的来说，用Go语言写业务确实可以很简单。它的并发模型、简洁语法和丰富的库支持，共同为开发者创造了一个高效、易用的编程环境。如果你正在寻找一种简单而强大的编程语言来编写业务逻辑，那么Go语言无疑是一个值得考虑的选择。无论是对于初创公司还是大型企业，Go语言都能提供稳定且可扩展的解决方案。
