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

[freebird1994]

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

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

[rioshikelong121]

DDD

[shenlanAZ]

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

[freebird1994]

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

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

[MinQ]

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

[freebird1994]

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

[wbrobot]

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

[namelosw]

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

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

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

[zhaorunze]

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

[MinQ]

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