这是一个创建于 1635 天前的主题，其中的信息可能已经有所发展或是发生改变。
在某些场景下。一个方法可能会涉及多次外部系统的 rpc 调用，多次的本地业务逻辑。意味着方法逻辑很重。最简单的方法当然就是一把梭。但是后续的维护成本是比较高的。我们系统的老代码都是一把梭的。。。
暂时的新业务接口是把方法拆分为业务原子方法（就是业务上不可再拆分的一个方法体）。在接口中依次执行。
当然在此要暂时忽略接口涉及层次的解耦问题。因为毕竟我们是搬砖的。
大家又有什么好的 idea 呢？能否借鉴一下
暂时的新业务接口是把方法拆分为业务原子方法（就是业务上不可再拆分的一个方法体）。在接口中依次执行。
当然在此要暂时忽略接口涉及层次的解耦问题。因为毕竟我们是搬砖的。
大家又有什么好的 idea 呢？能否借鉴一下
 |
1
rioshikelong121 2020-06-01 16:26:52 +08:00
DDD
|
 |
2
shenlanAZ 2020-06-01 17:05:25 +08:00
一个复杂的汽车应该如何设计制造
|
 |
3
freebird1994 OP |
 |
4
MinQ 2020-06-01 19:44:43 +08:00
业务拆分成原子，然后上 workflow ？
|
|
5
freebird1994 OP @MinQ 这个我的确有思考过。但感觉又有一点过度设计了……
|
 |
6
wbrobot 2020-06-01 22:11:40 +08:00
又不是不能用。。。。重构主要看业务情况：1 现在业务规模，是否已经瓶颈，2 未来业务规模，是否预期增长线性。。。如果都否，构个蛇皮~
|
 |
7
namelosw 2020-06-01 22:54:44 +08:00
@freebird1994 把贫血模型的的操作合成一个等价的充血操作，有业务意义的，然后作为 API 或者接口暴露。不一定是模型上的方法，只要 group 起来就好，然后用注释或者文档之类的显示标记这些是 API，怎么简单怎么来。
可读的目标就是暴露一套业务语言，这套业务语言就是这些 API，是一堆有业务意义的操作。之所以提出来这些 API 是为了不要和其他业务上不关心的方法混起来丢失重点。 这套 API 是最重要的，可能还是只有实现，但是名字起好了就成功一半了，至于抽不抽接口后面看着办。 |
 |
8
zhaorunze 2020-06-02 09:09:21 +08:00
自上而下的结构分解+自下而上的模型分析
|
|
9
MinQ 2020-06-02 09:16:51 +08:00
@freebird1994 这种情况适合那种原子比较多，业务流程比较深，但不同业务之间的原子通用性比较高的情况，如果原子之间不太能复用的话就不好使
|
Select Language