Golang Go语言中代码拆分模块或拆分包时，应该先根据功能分还是先根据业务分？
Golang Go语言中代码拆分模块或拆分包时，应该先根据功能分还是先根据业务分？
比如：
先根据功能分：
RpcServer.Message.SendMessage
RpcServer.Auth.Login
先根据业务分
Message.RpcServer.SendMessage
Message.HttpServer.GetMessageList
没有一刀切的情况
我的话一般 common 部分根据功能切分为主
其余根据业务>功能的顺序去切分为主（因为考虑到今后可能会变成 common ）
更多关于Golang Go语言中代码拆分模块或拆分包时，应该先根据功能分还是先根据业务分？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
https://medium.com/@hatajoe/clean-architecture-in-go-4030f11ec1b1 看下这篇 需要根据项目总体的预期架构来分
自然是要根据业务划分模块的，否则你和人沟通都不好沟通。业务人员只懂业务，业务是成体系的，你和他讲东一个西一个零散的功能，完全就是鸡同鸭讲。
然而，不同业务会有相同的功能需求，譬如用户、收款、退款之类，也是最正常不过的事情。这类共同的功能，则可以抽象出来，单独形成一个独立模块，业务需要的时候，调用就好了。现在流行微服务，基本上每个模块都可以做成一个独立服务。
没有什么是“应该的”。你要先明白自己要什么，才知道什么是“好”的。按照我的视角，好的模块划分的标准是
1、首先要让模块负责。从业务产出的角度来说，有可衡量的指标。你可以是按所谓的“功能”分，比如把处理 RPC 的中间件拆分成独立的库，让他们负责稳定性。也可以按所谓的“业务”分，比如这个模块就负责商品页的流量转化，如果流量转化效率高，他们就干得不错。
2、其次是让模块之间具有相对独立性。如果可能，一个需求需要改动的模块越少越好。参与的模块越少，就参与的人越少，就沟通越少，所以效率就会越高。
3、最后是鼓励模块的复用。好的架构是具有前瞻性的，可以今天的投资，明天拿到更多的回报。比如搞一些提高开发效率，搞一些和领域相关的中台沉淀的事情。
accountable >> autonomous > amortization
感觉这个 demo 太简单，太理想化了,在实际生产环境中，稍微复杂一点的项目并不合适。
例如 参数过滤，分页，那么 repository 这里必须要知道这些参数。当然你可以传到 repository 里面，参数多起来，整个函数看起来，非常丑。
又例如，事务处理，也是类似的
在Golang（Go语言）中拆分模块或包时，选择先根据功能分还是先根据业务分，实际上取决于项目的具体需求和规模，但通常建议采取一种综合策略，兼顾功能和业务逻辑。
首先，从功能角度出发拆分代码有助于保持代码的清晰和可维护性。例如，将数据处理、网络通信、数据库操作等通用功能分别封装到不同的包中，可以方便重用和测试。这种拆分方式特别适用于构建大型系统或库，因为它有助于减少代码间的依赖，提高模块化程度。
然而，对于业务逻辑紧密相关的代码，根据业务进行拆分也是非常重要的。这有助于开发人员快速理解代码的业务背景，以及不同部分之间的交互方式。在业务导向的拆分中，每个包或模块应该对应一个明确的业务领域或功能模块，如用户管理、订单处理、支付结算等。
因此，最佳实践是结合功能和业务逻辑进行代码拆分。可以先从功能角度将通用功能提取到独立包中，然后根据业务逻辑将相关功能组织到业务模块中。这种方式既保证了代码的复用性和模块化程度，又便于开发人员理解和维护业务逻辑。
总之，在Go语言中拆分模块或包时，需要综合考虑项目的具体情况，灵活运用功能和业务逻辑两种拆分方式，以达到最佳的代码组织效果。
