阿里高级技术专家方法论：如何写复杂业务代码？

时间 2019-11-24

原文原文链接

阿里妹导读：张建飞是阿里巴巴高级技术专家，一直在致力于应用架构和代码复杂度的治理。最近，他在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。结合实际的业务场景，Frank 沉淀了一套“如何写复杂业务代码”的方法论，在此分享给你们，相信一样的方法论能够复制到大部分复杂业务场景。数据库

一个复杂业务的处理过程

业务背景后端

简单的介绍下业务背景，零售通是给线下小店供货的B2B模式，咱们但愿经过数字化重构传统供应链渠道，提高供应链效率，为新零售助力。阿里在中间是一个平台角色，提供的是Bsbc中的service的功能。设计模式

商品力是零售通的核心所在，一个商品在零售通的生命周期以下图所示：架构

在上图中红框标识的是一个运营操做的“上架”动做，这是很是关键的业务操做。上架以后，商品就能在零售通上面对小店进行销售了。由于上架操做很是关键，因此也是商品域中最复杂的业务之一，涉及不少的数据校验和关联操做。
针对上架，一个简化的业务流程以下所示：ide

过程分解工具

像这么复杂的业务，我想应该没有人会写在一个service方法中吧。一个类解决不了，那就分治吧。学习

说实话，能想到分而治之的工程师，已经作的不错了，至少比没有分治思惟要好不少。我也见过复杂程度至关的业务，连分解都没有，就是一堆方法和类的堆砌。ui

不过，这里存在一个问题：即不少同窗过分的依赖工具或是辅助手段来实现分解。好比在咱们的商品域中，相似的分解手段至少有3套以上，有自制的流程引擎，有依赖于数据库配置的流程处理：spa

本质上来说，这些辅助手段作的都是一个pipeline的处理流程，没有其它。所以，我建议此处最好保持KISS（Keep It Simple and Stupid），即最好是什么工具都不要用，次之是用一个极简的Pipeline模式，最差是使用像流程引擎这样的重方法。设计

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

回到商品上架的问题，这里问题核心是工具吗？是设计模式带来的代码灵活性吗？显然不是，问题的核心应该是如何分解问题和抽象问题，知道金字塔原理的应该知道，此处，咱们可使用结构化分解将问题解构成一个有层级的金字塔结构：

按照这种分解写的代码，就像一本书，目录和内容清晰明了。

以商品上架为例，程序的入口是一个上架命令（OnSaleCommand）, 它由三个阶段（Phase）组成。

@Command
public class OnSaleNormalItemCmdExe {

    @Resource
    private OnSaleContextInitPhase onSaleContextInitPhase;
    @Resource
    private OnSaleDataCheckPhase onSaleDataCheckPhase;
    @Resource
    private OnSaleProcessPhase onSaleProcessPhase;

    @Override
    public Response execute(OnSaleNormalItemCmd cmd) {

        OnSaleContext onSaleContext = init(cmd);

        checkData(onSaleContext);

        process(onSaleContext);

        return Response.buildSuccess();
    }

    private OnSaleContext init(OnSaleNormalItemCmd cmd) {
        return onSaleContextInitPhase.init(cmd);
    }

    private void checkData(OnSaleContext onSaleContext) {
        onSaleDataCheckPhase.check(onSaleContext);
    }

    private void process(OnSaleContext onSaleContext) {
        onSaleProcessPhase.process(onSaleContext);
    }
}

每一个Phase又能够拆解成多个步骤（Step），以OnSaleProcessPhase为例，它是由一系列Step组成的：

@Phase
public class OnSaleProcessPhase {

    @Resource
    private PublishOfferStep publishOfferStep;
    @Resource
    private BackOfferBindStep backOfferBindStep;
    //省略其它step

    public void process(OnSaleContext onSaleContext){
        SupplierItem supplierItem = onSaleContext.getSupplierItem();

        // 生成OfferGroupNo
        generateOfferGroupNo(supplierItem);

       // 发布商品
        publishOffer(supplierItem);

        // 先后端库存绑定 backoffer域
        bindBackOfferStock(supplierItem);

        // 同步库存路由 backoffer域
        syncStockRoute(supplierItem);

        // 设置虚拟商品拓展字段
        setVirtualProductExtension(supplierItem);

        // 发货保障打标 offer域
        markSendProtection(supplierItem);

        // 记录变动内容ChangeDetail
        recordChangeDetail(supplierItem);

        // 同步供货价到BackOffer
        syncSupplyPriceToBackOffer(supplierItem);

        // 若是是组合商品打标，写扩展信息
        setCombineProductExtension(supplierItem);

        // 去售罄标
        removeSellOutTag(offerId);

        // 发送领域事件
        fireDomainEvent(supplierItem);

        // 关闭关联的待办事项
        closeIssues(supplierItem);
    }
}

看到了吗，这就是商品上架这个复杂业务的业务流程。须要流程引擎吗？不须要，须要设计模式支撑吗？也不须要。对于这种业务流程的表达，简单朴素的组合方法模式（Composed Method）是再合适不过的了。

所以，在作过程分解的时候，我建议工程师不要把太多精力放在工具上，放在设计模式带来的灵活性上。而是应该多花时间在对问题分析，结构化分解，最后经过合理的抽象，造成合适的阶段（Phase）和步骤（Step）上。

过程分解后的两个问题

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

领域知识被割裂肢解

什么叫被肢解？由于咱们到目前为止作的都是过程化拆解，致使没有一个聚合领域知识的地方。每一个Use Case的代码只关心本身的处理流程，知识没有沉淀。

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

代码的业务表达能力缺失

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

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

boolean isCombineProduct = supplierItem.getSign().isCombProductQuote();

// supplier.usc warehouse needn't check
if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) {
// quote warehosue check
if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) {
    throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，不能发布Offer，请联系仓配运营人员，创建品仓关系！");
}
// inventory amount check
Long sellableAmount = 0L;
if (!isCombineProduct) {
    sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList());
} else {
    //组套商品
    OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId());
    if (backOffer != null) {
        sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale();
    }
}
if (sellableAmount < 1) {
    throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + supplierItem.getId() + "]");
}
}

然而，若是咱们在系统中引入领域模型以后，其代码会简化为以下：

return;
}

if (backOffer.isNonInWarehouse()){
    throw new BizException("亲，不能发布Offer，请联系仓配运营人员，创建品仓关系！");
}

if (backOffer.getStockAmount() < 1){
    throw new BizException("亲，实仓库存必须大于0才能发布，请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]");
}

有没有发现，使用模型的表达要清晰易懂不少，并且也不须要作关于组合品的判断了，由于咱们在系统中引入了更加贴近现实的对象模型（CombineBackOffer继承BackOffer），经过对象的多态能够消除咱们代码中的大部分的if-else。

过程分解+对象模型

经过上面的案例，咱们能够看到有过程分解要好于没有分解，过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case，若是采用过程分解+对象模型的方式，最终咱们会获得一个以下的系统结构：

写复杂业务的方法论

经过上面案例的讲解，我想说，我已经交代了复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析。

接下来，让咱们把上面的案例进行进一步的提炼，造成一个可落地的方法论，从而能够泛化到更多的复杂业务场景。

上下结合

所谓上下结合，是指咱们要结合自上而下的过程分解和自下而上的对象建模，螺旋式的构建咱们的应用系统。这是一个动态的过程，两个步骤能够交替进行、也能够同时进行。

这两个步骤是相辅相成的，上面的分析能够帮助咱们更好的理清模型之间的关系，而下面的模型表达能够提高咱们代码的复用度和业务语义表达能力。

其过程以下图所示：

使用这种上下结合的方式，咱们就有可能在面对任何复杂的业务场景，都能写出干净整洁、易维护的代码。

能力下沉

通常来讲实践DDD有两个过程：

套概念阶段：了解了一些DDD的概念，而后在代码中“使用”Aggregation Root，Bounded Context，Repository等等这些概念。更进一步，也会使用必定的分层策略。然而这种作法通常对复杂度的治理并无多大做用。

融会贯通阶段：术语已经再也不重要，理解DDD的本质是统一语言、边界划分和面向对象分析的方法。

大致上而言，我大概是在1.7的阶段，由于有一个问题一直在困扰我，就是哪些能力应该放在Domain层，是否是按照传统的作法，将全部的业务都收拢到Domain上，这样作合理吗？说实话，这个问题我一直没有想清楚。

由于在现实业务中，不少的功能都是用例特有的（Use case specific）的，若是“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反，这种收拢会致使Domain层的膨胀过厚，不够纯粹，反而会影响复用性和表达能力。

鉴于此，我最近的思考是咱们应该采用能力下沉的策略。

所谓的能力下沉，是指咱们不强求一次就能设计出Domain的能力，也不须要强制要求把全部的业务功能都放到Domain层，而是采用实用主义的态度，即只对那些须要在多个场景中须要被复用的能力进行抽象下沉，而不须要复用的，就暂时放在App层的Use Case里就行了。

注：Use Case是《架构整洁之道》里面的术语，简单理解就是响应一个Request的处理过程。

经过实践，我发现这种按部就班的能力下沉策略，应该是一种更符合实际、更敏捷的方法。由于咱们认可模型不是一次性设计出来的，而是迭代演化出来的。

下沉的过程以下图所示，假设两个use case中，咱们发现uc1的step3和uc2的step1有相似的功能，咱们就能够考虑让其下沉到Domain层，从而增长代码的复用性。

指导下沉有两个关键指标：

复用性
内聚性

复用性是告诉咱们When（何时该下沉了），即有重复代码的时候。内聚性是告诉咱们How（要下沉到哪里），功能有没有内聚到恰当的实体上，有没有放到合适的层次上（由于Domain层的能力也是有两个层次的，一个是Domain Service这是相对比较粗的粒度，另外一个是Domain的Model这个是最细粒度的复用）。

好比，在咱们的商品域，常常须要判断一个商品是否是最小单位，是否是中包商品。像这种能力就很是有必要直接挂载在Model上。

public class CSPU {
    private String code;
    private String baseCode;
    //省略其它属性

    /**
     * 单品是否为最小单位。
     *
     */
    public boolean isMinimumUnit(){
        return StringUtils.equals(code, baseCode);
    }

    /**
     * 针对中包的特殊处理
     *
     */
    public boolean isMidPackage(){
        return StringUtils.equals(code, midPackageCode);
    }
}

以前，由于老系统中没有领域模型，没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的，至少我在第一眼看到这个代码的时候，是彻底不知道什么意思。

业务技术要怎么作

写到这里，我想顺便回答一下不少业务技术同窗的困惑，也是我以前的困惑：即业务技术究竟是在作业务，仍是作技术？业务技术的技术性体如今哪里？

经过上面的案例，咱们能够看到业务所面临的复杂性并不亚于底层技术，要想写好业务代码也不是一件容易的事情。业务技术和底层技术人员惟一的区别是他们所面临的问题域不同。

业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。好比，若是你须要去开发Pandora，你就要对Classloader有更加深刻的了解才行。

可是，无论是业务技术仍是底层技术人员，有一些思惟和能力都是共通的。好比，分解问题的能力，抽象思惟，结构化思惟等等。

用个人话说就是：“作很差业务开发的，也作很差技术底层开发，反之亦然。业务开发一点都不简单，只是咱们不少人把它作“简单”了。

所以，若是从变化的角度来看，业务技术的难度一点不逊色于底层技术，其面临的挑战甚至更大。所以，我想对广大的从事业务技术开发的同窗说：沉下心来，夯实本身的基础技术能力、OO能力、建模能力... 不断提高抽象思惟、结构化思惟、思辨思惟... 持续学习精进，写好代码。咱们能够在业务技术岗作的很”技术“！。

后记

这篇文章是我最近思考的一些总结，大部分思想是继承自我原来写的COLA架构，该架构已经开源，目前在集团内外都有比较普遍的使用。

这一篇主要是在COLA的基础上，针对复杂业务场景，作了进一步的架构落地。我的感受能够做为COLA的最佳实践来使用。

另外，本文讨论的问题之大和篇幅之短是不成正比的。缘由是我假定你已经了解了一些DDD和应用架构的基础知识。若是以为在理解上有困难，我建议能够先看下《领域驱动设计》和《架构整洁之道》这两本书。

若是没有那么多时间，也能够快速浏览下我以前的两篇文章应用架构之道和领域建模去知晓一下我以前的思想脉络。

原文连接本文为云栖社区原创内容，未经容许不得转载。