如何写复杂业务代码？

讲，这些辅助手段做的都是一个pipeline的处理流程，没有其它。因此，我建议此处最好保持KISS(Keep It Simple and Stupid)，即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。

除非你的应用有极强的流程可视化和编排的诉求，否则我非常不推荐使用流程引擎等工具。第一，它会引入额外的复杂度，特别是那些需要持久化状态的流程引擎;第二，它会割裂代码，导致阅读代码的不顺畅。大胆断言一下，全天下估计80%对流程引擎的使用都是得不偿失的。

回到商品上架的问题，这里问题核心是工具吗?是设计模式带来的代码灵活性吗?显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，我们可以使用结构化分解将问题解构成一个有层级的金字塔结构了吗，这就是商品上架这个复杂业务的业务流程。需要流程引擎吗?不需要，需要设计模式支撑吗?也不需要。对于这种业务流程的表达，简单朴素的组合方法模式(Composed Method)是再合适不过的了。

因此，在做过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后通过合理的抽象，形成合适的阶段(Phase)和步骤(Step)上。后的两个问题

的确，使用过程分解之后的代码，已经比以前的代码更清晰、更容易维护了。不过，还有两个问题值得我们去关注一下：

• 领域知识被割裂肢解

什么叫被肢解?因为我们到目前为止做的都是过程化拆解，导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程，知识没有沉淀。

相同的业务逻辑会在多个Use Case中被重复实现，导致代码重复度高，即使有复用，最多也就是抽取一个util，代码对业务语义的表达能力很弱，从而影响代码的可读性和可理解性。

• 代码的业务表达能力缺失

试想下，在过程式的代码中，所做的事情无外乎就是取数据--做计算--存数据，在这种情况下，要如何通过代码显性化的表达我们的业务呢?说实话，很难做到，因为我们缺失了模型，以及模型之间的关系。脱离模型的业务表达，是缺少韵律和灵魂的。

举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品(CombineBackOffer)其库存的处理会和普通品不一样。原来的代码是这么写的：

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!