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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

这是一个创建于 2250 天前的主题，其中的信息可能已经有所发展或是发生改变。

比如：
先根据功能分：
RpcServer.Message.SendMessage
RpcServer.Auth.Login
先根据业务分
Message.RpcServer.SendMessage
Message.HttpServer.GetMessageList

rpcserver

message

根据

auth

10 条回复 • 2018-10-15 11:47:02 +08:00

xy90321

2018-10-04 08:42:21 +08:00 via iPhone

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

hualongbei

2018-10-04 09:07:09 +08:00

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

alqaz

2018-10-04 09:44:28 +08:00

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

scnace

2018-10-04 11:16:46 +08:00 via Android

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

xuanbg

2018-10-04 11:27:45 +08:00

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

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

HuHui

2018-10-04 12:00:52 +08:00 via Android

看复杂度

taowen

2018-10-04 22:39:16 +08:00

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

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

accountable >> autonomous > amortization

taowen

2018-10-04 22:40:40 +08:00

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

darklowly

2018-10-10 07:10:35 +08:00

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

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

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

reus

2018-10-15 11:47:02 +08:00

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