一文教会你如何写复杂业务代码.docxVIP

一文教会你如何写简单业务代码 简约的引见下业务背景，零售通是给线下小店供货的B2B模式，我们期望通过数字化重构传统供应链渠道，提升供应链效率，为新零售助力。阿里在两头是一个平台角色，供应的是Bsbc中的service的功能。 在商品域，运营会操作一个“上架”动作，上架之后，商品就能在零售通上面对小店进行销售了。是零售通业务格外关键的业务操作之一，因而涉及很多的数据校验和关联操作。 针对上架，一个简化的业务流程如下所示： 过程分解 像这么简单的业务，我想应当没有人会写在一个service方法中吧。一个类处理不了，那就分治吧。 说实话，能想到分而治之的工程师，已经做的不错了，至少比没有分治思维要好很多。我也见过简单程度相当的业务，连分解都没有，就是一堆方法和类的堆砌。 不过，这里存在一个问题：即很多同学过度的依靠工具或是协助手段来实现分解。比如在我们的商品域中，类似的分解手段至少有3套以上，有自制的流程引擎，有依靠于数据库配置的流程处理： 本质上来讲，这些协助手段做的都是一个pipeline的处理流程，没有其它。因而，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。 除非你的应用有极强的流程可视化和编排的诉求，否则我格外不推举使用流程引擎等工具。第一，