第一，所谓聚合罗里吧嗦一大堆定义，其本质就是面向对象设计的 “封装性”
第二，mongodb 官网早期首页上赫然写着 “mongodb 的文档性设计天然契合习惯于对象思维的程序员”，只不过现在都被广告代替了
所以，你是对的
另外，没什么可担心的，都是设计思想问题，DDD 是个设计思想

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

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

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

@Hanggi 来来来试试这个 https://github.com/framework-arp/ARP4G

//从仓库取出 order
order, _ := serv.orderRepository.Take(ctx, orderId)

看上去是不是很自然？

知道了，是说一个提示未做任务的系统，这个是挺小巧的

@seakingii 不明白 todo 是个啥？不应该是未实现功能点吗

@acehinnnqru go 语言的业务开发框架 [ARP4G]( https://github.com/zhengchengdong/ARP4G)

@morty0 我们希望 ARP 像玩具一样简单:) 通过总结这些年我们上线的几十个业务系统，去除了很多不必要的复杂性，沉淀出了 ARP 设计方法，有任何疑问和想法欢迎讨论