代码拆分模块或者拆分包的时候，应该先根据功能分还是先根据业务分？

没有一刀切的情况
我的话一般 common 部分根据功能切分为主
其余根据业务>功能的顺序去切分为主（因为考虑到今后可能会变成 common ）

一楼 +1
单纯根据功能分的或许是很小的项目？
我一般根据业务划分，功能公用的抽出来

牵扯到业务肯定是业务了。相对底层的根据功能。

https://medium.com/@hatajoe/clean-architecture-in-go-4030f11ec1b1 看下这篇 需要根据项目总体的预期架构来分

自然是要根据业务划分模块的，否则你和人沟通都不好沟通。业务人员只懂业务，业务是成体系的，你和他讲东一个西一个零散的功能，完全就是鸡同鸭讲。

然而，不同业务会有相同的功能需求，譬如用户、收款、退款之类，也是最正常不过的事情。这类共同的功能，则可以抽象出来，单独形成一个独立模块，业务需要的时候，调用就好了。现在流行微服务，基本上每个模块都可以做成一个独立服务。

看复杂度

没有什么是“应该的”。你要先明白自己要什么，才知道什么是“好”的。按照我的视角，好的模块划分的标准是

1、首先要让模块负责。从业务产出的角度来说，有可衡量的指标。你可以是按所谓的“功能”分，比如把处理 RPC 的中间件拆分成独立的库，让他们负责稳定性。也可以按所谓的“业务”分，比如这个模块就负责商品页的流量转化，如果流量转化效率高，他们就干得不错。
2、其次是让模块之间具有相对独立性。如果可能，一个需求需要改动的模块越少越好。参与的模块越少，就参与的人越少，就沟通越少，所以效率就会越高。
3、最后是鼓励模块的复用。好的架构是具有前瞻性的，可以今天的投资，明天拿到更多的回报。比如搞一些提高开发效率，搞一些和领域相关的中台沉淀的事情。

accountable >> autonomous > amortization

更多信息可以参考我在 medium 上写的文章： https://medium.com/software-engineering-problems

@scnace 感觉这个 demo 太简单，太理想化了,在实际生产环境中，稍微复杂一点的项目并不合适。

例如 参数过滤，分页，那么 repository 这里必须要知道这些参数。当然你可以传到 repository 里面，参数多起来，整个函数看起来，非常丑。

又例如，事务处理，也是类似的

Send
Login
分那么多干嘛，以为自己系统很大吗。