一个复杂的业务方法应该如何拆分设计？

V2EX = way to explore

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

已注册用户请登录

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

在某些场景下。一个方法可能会涉及多次外部系统的 rpc 调用，多次的本地业务逻辑。意味着方法逻辑很重。最简单的方法当然就是一把梭。但是后续的维护成本是比较高的。我们系统的老代码都是一把梭的。。。
暂时的新业务接口是把方法拆分为业务原子方法（就是业务上不可再拆分的一个方法体）。在接口中依次执行。

当然在此要暂时忽略接口涉及层次的解耦问题。因为毕竟我们是搬砖的。
大家又有什么好的 idea 呢？能否借鉴一下

方法

拆分

业务

方法体

9 条回复 • 2020-06-02 09:16:51 +08:00

rioshikelong121

2020-06-01 16:26:52 +08:00

DDD

shenlanAZ

2020-06-01 17:05:25 +08:00

一个复杂的汽车应该如何设计制造

freebird1994

2020-06-01 17:27:09 +08:00

@rioshikelong121 额，系统是基于贫血模型。DDD 应该不行

@shenlanAZ 老哥说笑了，这顶多就是个零件。 -.-

MinQ

2020-06-01 19:44:43 +08:00

业务拆分成原子，然后上 workflow ？

freebird1994

2020-06-01 22:06:59 +08:00 via Android

@MinQ 这个我的确有思考过。但感觉又有一点过度设计了……

wbrobot

2020-06-01 22:11:40 +08:00

又不是不能用。。。。重构主要看业务情况：1 现在业务规模，是否已经瓶颈，2 未来业务规模，是否预期增长线性。。。如果都否，构个蛇皮~

namelosw

2020-06-01 22:54:44 +08:00

@freebird1994 把贫血模型的的操作合成一个等价的充血操作，有业务意义的，然后作为 API 或者接口暴露。不一定是模型上的方法，只要 group 起来就好，然后用注释或者文档之类的显示标记这些是 API，怎么简单怎么来。

可读的目标就是暴露一套业务语言，这套业务语言就是这些 API，是一堆有业务意义的操作。之所以提出来这些 API 是为了不要和其他业务上不关心的方法混起来丢失重点。

这套 API 是最重要的，可能还是只有实现，但是名字起好了就成功一半了，至于抽不抽接口后面看着办。

zhaorunze

2020-06-02 09:09:21 +08:00

自上而下的结构分解+自下而上的模型分析

MinQ

2020-06-02 09:16:51 +08:00

@freebird1994 这种情况适合那种原子比较多，业务流程比较深，但不同业务之间的原子通用性比较高的情况，如果原子之间不太能复用的话就不好使