最近工作中，发现其他人员开发的模块功能中，在catch语句块中调用了业务方法，目的是当try语句块中的业务逻辑执行过程中发生异常，再执行catch语句块中代码。

      上述情况的业务场景是这样的，try语句块中查询redis缓存（try中查询redis的代码有调用了其他开发人员写的逻辑比较复杂的方法，且多个方法调用），catch语句块中查询后端数据库，开发者意图很明显，就是如果查询redis缓存出现异常，则查询后端数据库，看似很完美的代码设计逻辑。但是完美下面也存在一定几率的风险。

       风险分析。暂定该开发人员叫A，如果try语句块中逻辑比较复杂，且调用了其他开发人员（名字为B）的方法，这时候开发人员B在自己的方法中也利用catch捕获了异常，而不是向上抛出异常，这时候问题出现了，A写的代码中catch语句块的业务逻辑有可能不会执行，这就违背了A的设计意图，也就产生了非常讨厌的逻辑bug。开发人员都知道逻辑bug的原因很难找的。

   所以，在日常开发工作，catch语句块中尽量不要写业务逻辑，就打印写异常日志就可以了。

 

1.确定逻辑单元
2.对逻辑单元做单元测试
确定逻辑单元的方法有很多，说简单其道理就像我们平时整理自己的屋子，只要将各种东西分门别类的放整齐就可以了；说复杂的，大家可以看看现在市面上的各种设计模式，它们又像一把梳子，帮助我们将杂乱无章的业务逻辑理顺。事实上，不管你怎么写，你的代码是由逻辑单元组成的，因为你的代码的确是在描述业务逻辑，就算是只有一个逻辑单元存在。
然而事情并没有那么简单，逻辑单元划分的粒度的确定是另外一个头疼的问题。举一个例子，创建订单。创建订单过程包含：获取订单相关资源；检查资源可用性；写入订单数据。检查资源可用性过程包含：检查服务员的资质；检查服务员的时间；检查该项订单的时间范围等等。而检查服务员的资质过程包括：获取服务员的工作区间；获取该服务员在该工作区间中的资质....。以上只是我举的一个例子，在显示环境中的大多数情况下，其实我们根本不能很好的确定到底该将这个所谓的逻辑单元确定到什么程度。
其实没有什么，当我们不能很好的完成一件事情的时候，我们应该想到还有其它办法来弥补---这就是单元测试。实际上我们没有必要花很多时间去评价到底该将逻辑单元确定到什么程度。我们只需要确定这个逻辑单元完全实现了它本身所蕴含的业务逻辑。因此我们需要对逻辑单元做单元测试。
实际上，从我们一出生我们就开始完平衡游戏。在这里，逻辑单元和单元测试就是一种平衡。而分析这种平衡的最好方法就是先假设这个平衡不存在会是什么样子。假设我们只一味强调逻辑单元，那么逻辑单元可能会被分得很小，到头来，代码一样会变得难以维护；假设我们一味强调单元测试，我们同样会为此付出高昂的成本。所以我们需要在这个当中找到平衡。而这才是需要我们积累的经验。

项目组在和外部系统对接，花了好长一段时间对以前的打印逻辑做修改，修改了8次的bug，才实现了当前的外接系统的打印功能，上线的前一刻又发现此次的改动对以前的逻辑产生关联影响，哎，不谈了，原因很简单，随着外接系统的增多，实现的打印方式和功能已经很多了，而此时几千行的代码看看已经让人崩溃了，改动的难度就更大了。
不得不重构了，梳理业务和代码逻辑后，决定采用工厂+策略的模式进行重构。
工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来。


简单工厂实现客户买宝马的例子：




class Factory {
  

  

    static function  createBMW(type){  

        switch (type) {  

          case 320:  

             return new BWM320();  

          case 523:  

             return new BMW523();
   

   }  

} 


工厂实现客户买宝马车的例子：




/** 

 * 创建工厂的接口 

 * 

 */  

interface FactoryBMW {   

       function createBMW();   

}   

  

  

/** 

 *  

 * 创建BWM320车 

 */  

class FactoryBWM320 implements FactoryBMW {  

   function  createBMW($type){  

      return new BWM320();  

   }  

  

}  

  

  

/** 

 *  

 * 创建BWM523车 

 */  

class FactoryBWM523 implements FactoryBMW {  

   function  createBMW($type){  

      return new BMW523();  

   }  

} 


抽象工厂的例子：




抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象 ，而且使用抽象工厂模式还要满足一下条件：

     1)系统中有多个产品族，而系统一次只可能消费其中一族产品。 

     2)同属于同一个产品族的产品以其使用。 
抽象工厂模式的各个角色（和工厂方法一样）： 
     1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 
     2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
     3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。
     4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。


策略模式：定义了不同的算法族，并且之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

Context(应用场景):
l         需要使用ConcreteStrategy提供的算法。
l         内部维护一个Strategy的实例。
l         负责动态设置运行时Strategy具体的实现算法。
l         负责跟Strategy之间的交互和数据传递。
Strategy(抽象策略类)：
l         定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。
ConcreteStrategy(具体策略类)：
l         实现了Strategy定义的接口，提供具体的算法实现。

有了上面的知识，重构就理顺了。外部关联系统部需要知道我怎么实现打印的，只需要告诉我打印需要的内容和打印机就好了。
关联系统A需要打印a,b,c三种类型的材料，并且采用彩色打印和黑白打印两种方式混合的方式。
在我们系统中，目前支持单页彩打，单页黑白打印，多页彩打，多页双面彩打，多页双面黑白打，以及以上的方式是否需要盖章，是否需要防伪水印，是否需要电子签名等多种方式的打印。讲以上的打印功能分成打印策略及子类，盖章策略及子类，防伪策略及子类三个策略类。
采用抽象工厂的方式，根据A系统的要求，在抽象工厂中生成适合的工厂类，调用合适的策略类就搞定了，再增加关联系统的时候，只需要再增加策略方法就搞定了。
重构前，原来的多个外部关联系统的N种打印逻辑代码有近4000行，重构后用1000多行代码完成整个流程，简单明了，呵呵。

了解我的人都知道，我一直在致力于应用架构和代码复杂度的治理。

这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景，如何在架构和代码层面进行应对，是一个新课题。针对该命题，我进行了比较细致的思考和研究。结合实际的业务场景，我沉淀了一套“如何写复杂业务代码”的方法论，在此分享给大家。

我相信，同样的方法论可以复制到大部分复杂业务场景。

一个复杂业务的处理过程

业务背景

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

在商品域，运营会操作一个“上架”动作，上架之后，商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一，因此涉及很多的数据校验和关联操作。

针对上架，一个简化的业务流程如下所示： 

过程分解

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

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

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

本质上来讲，这些辅助手段做的都是一个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）上。

过程分解后的两个问题

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

1、领域知识被割裂肢解

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

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

2、代码的业务表达能力缺失

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

举个例子，在上架过程中，有一个校验是检查库存的，其中对于组合品（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() + "]");
}
}


然而，如果我们在系统中引入领域模型之后，其代码会简化为如下：

if(backOffer.isCloudWarehouse()){
    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有两个过程：

1. 套概念阶段

了解了一些DDD的概念，然后在代码中“使用”Aggregation Root，Bonded Context，Repository等等这些概念。跟进一步，也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。

2. 融会贯通阶段

术语已经不再重要，理解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能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进，写好代码。我们可以在业务技术岗做的很”技术“！。