解构领域驱动设计(一):为什么领域驱动设计能够解决软件复杂性

By | 2019年1月12日

1 为什么我要研究领域驱动设计

1.1 设计方法各样且代码无法反映设计

我大概从2017年10月份开始研究DDD,当时在一家物流信息化的公司任职架构师,研究DDD的初衷在于为团队寻找一种软件设计的方法论。作为架构师,经常参与设计评审,包括:需求评审、设计评审、代码评审。在评审过程中,有一点感受非常深,就是评审过程非常痛苦且几乎没有效率和成果。让我痛苦的地方有:

  • 每一个系统分析师都是基于自己的方式来进行设计功能,有的用类图、有的基于流程图,有的详细、有的粗放,更麻烦的是,大家对业务背景的理解程度完全不同,很难找出设计的不合理性。
  • 评审代码时,我几乎很难将其与设计对应起来,看设计我已经够痛苦了,还要被这些代码再虐待一遍,实在痛苦至极,这样的代码评审也就变成了代码规范性、代码设计优雅度的评审,很难找出代码业务逻辑的问题。让代码正确的反应设计,是当时评审过程中碰到的一个更大的问题。

1.2 代码质量很难有效提升

在承担架构师之前,我的另一个职责是技术管理,做的工作是与软件质量相关的。当时加入一个大概2000万规模的项目,有大约100开发人员参与,开发周期大概1年。加入该团队在开发的过程中,发现了两个问题:

  • 每一个BA(可以理解为PD)设计的产品界面操作习惯都不一样,所有的开发人员做出来的界面的操作也完全不同。但是,这是一个面向物流行业的信息化软件,操作习惯的一致性很重要。
  • 代码非常混乱,没有任何的规范可言,看代码简直想吐。

基于第一个问题,我定义了统一的界面规范,这个界面规范通过和公司的PMO合作将其融入到工程过程中,作为开发人员必须遵循的规范。第二个问题,我则花费了很多的时间来尝试解决(大概有2年时间都与代码质量做斗争),最终与寻找统一的设计方法殊途同归。

如何让我们的代码变得更加干净,我在执行的过程中,按照以下步骤一步一步的执行。

  • 定义了统一的代码规范,基于界面规范的基础上,统一定义了模板工程,这些模板工程都有很好的代码基因。
  • 定义了代码规范的培训教程,包括基本的书写规范、《代码整洁之道》、《重构技巧》。
  • 定义了代码规范、代码评审制度,写入PMO定义的过程工作,作为开发人员遵循的制度。
  • 通过代码评审提升质量太慢,为了大规模快速推广,引入了SonarQube,定义了软件代码质量的度量方法,软件的代码质量分数由:圈复杂度、重复率、代码规模问题、SonarQube扫描的问题数四个维度来衡量。在度量方法之上,定义了代码质量管理制度,每周扫描软件获得详细的代码质量报告,发送给相应的产品负责人,将代码质量管理制度也融入PMO的工程过程里面,全公司进行推广,由产品负责人负责本部分的代码质量提升。

基于以上的代码质量管理方法,我认为已经是做的相当不错,但是非常遗憾的是,当我抽样评审产品的代码时,我依然感到无比沮丧,软件的代码还是太复杂、太难看懂了,与《代码整洁之道》的要求相差太远了,我耗费了1年多的工作几乎毫无成果可言。因此,我在深深思考,在编码层面,定义了规范、做了优雅编码培训、定义了编写优秀代码的相关制度,就为了让开发人员把代码写好,使代码看起来更加清晰,软件更加容易维护,为什么还是无法实现?

2 软件复杂性的根源

贫血模型是软件复杂性的根源。贫血模型本质是面向数据的设计,面向过程的编码。基于贫血模型的分层架构,通常分为UI层、业务逻辑层、数据访问层、贫血模型层,贫血模型与数据模型一致,业务逻辑主要集中在业务逻辑层,业务逻辑层非常厚重。业务逻辑实现过程中,混杂了上层UI展现逻辑、数据库访问、缓存等各种逻辑,业务逻辑很凌乱的分散在各个层和关联对象,被非业务逻辑的代码隔离。通过业务逻辑层来还原真实的业务逻辑非常的困难,因此,很难从代码反映其设计,并且,复杂度会随着需求的变更变得更加复杂。

以下是一段示例基于贫血模型开发的代码。

public OrderDto signOrder(Order order) {
    Assert.notNull(order, "OrderDto can not be null.");
    OrderDto result = new OrderDto();
    result.setIsOperationSuccess(true);
    if (null == order.getId()) {
        result.setIsOperationSuccess(false);
        result.setOperationMassage("id不能为空。");
        return result;
    }
    OrderCondition orderCondition = new OrderCondition();
    orderCondition.setId(order.getId());
    order = orderMapper.selectOne(orderCondition);
    if (null == order) {
        result.setIsOperationSuccess(false);
        result.setOperationMassage("该订单不存在。");
        return result;
    }
    if (order.getOrderStatus() != Integer.valueOf(StatusEnum.ORDER_STATUS.ORDER_WAIT_RECEIVE.getCode())) {
        result.setIsOperationSuccess(false);
        result.setOperationMassage("订单号:{" + order.getOrderNo() + "}不是待收货状态,不能进行签收。");
        return result;
    }
    // 该订单下的所有商品的实收数(发货数量)必须都大于0
    boolean validDeliveryCount = true;
    Double orderTotalAmount = 0d;
    List<OrderGoodsDto> orderGoodsList = orderGoodsBiz.selectOrderGoodsByOrderId(order.getId());
    List<OrderGoods> orderGoodsListForUpdate = new ArrayList<>();
    if (EmptyUtil.isNotEmpty(orderGoodsList)) {
        for (OrderGoodsDto orderGoods : orderGoodsList) {
            if (null == orderGoods.getDeliveredNum() || orderGoods.getDeliveredNum() <= 0) {
                validDeliveryCount = false;
            } else {
                // 根据商品发货数量重新计算订单总金额......
                Double price = (null == orderGoods.getDiscountPrice() ? orderGoods.getOriginalPrice() : orderGoods.getDiscountPrice());
                Integer goodsNum = (null == orderGoods.getDeliveredNum() ? 0 : orderGoods.getDeliveredNum());
                orderTotalAmount += price * goodsNum;
                // 更新orderGoods的收货数量
                orderGoods.setReceivedNum(goodsNum);
                OrderGoods orderGoodsForUpdate = new OrderGoods();
                BeanUtils.copyProperties(orderGoods, orderGoodsForUpdate);
                orderGoodsListForUpdate.add(orderGoodsForUpdate);
            }
        }
    }
    if (!validDeliveryCount) {
        result.setIsOperationSuccess(false);
        result.setOperationMassage("订单号:" + order.getOrderNo() + ",订单下所有商品都已发货才可进行签收操作,请确认。");
        return result;
    }
    order.setOrderStatus(Integer.valueOf(StatusEnum.ORDER_STATUS.ORDER_SIGN.getCode()));
    order.setOrderTotalAmount(orderTotalAmount);
    order.setPaymentAmount(orderTotalAmount);
    order.setUnpaidAmount(orderTotalAmount);
    update(order);
    orderGoodsBiz.batchUpdate(orderGoodsListForUpdate);
    List<Order> orders = new ArrayList<Order>();
    orders.add(order);
    saveRouteMessage(orders);
    return result;
}

 

类似这样的代码非常常见,通过阅读这段业务逻辑代码,可以发现它处理了以下的任务:
(1)返回结果的处理。
(2)数据库访问。
(3)关联对象的数据库访问。
(4)业务规则。

业务规则代码混杂在各种任务的代码中,通过代码还原业务规则会越来越复杂且随着时间推移,代码逻辑会越来越偏离设计。作为软件系统最核心的部分——业务规则,如果我们仅仅将其从其它任务中剥离,我们的代码将演化如下。

public void signOrder(Order order) {
    Assert.notNull(order, "OrderDto can not be null.");

    if (order.getOrderStatus() != Integer.valueOf(StatusEnum.ORDER_STATUS.ORDER_WAIT_RECEIVE.getCode())) {
        throw new BusinessException(“订单号:{" + order.getOrderNo() + "}不是待收货状态,不能进行签收。");
    }

    // 该订单下的所有商品的实收数(发货数量)必须都大于0
    boolean validDeliveryCount = true;
    Double orderTotalAmount = 0d;

    List<OrderGoods> orderGoodsList = order.getOrderGoods();
    if (EmptyUtil.isNotEmpty(orderGoodsList)) {
        for (OrderGoods orderGoods : orderGoodsList) {
            if (null == orderGoods.getDeliveredNum() || orderGoods.getDeliveredNum() <= 0) {
                validDeliveryCount = false;
            } else {
                // 根据商品发货数量重新计算订单总金额......
                Double price = (null == orderGoods.getDiscountPrice() ? orderGoods.getOriginalPrice() : orderGoods.getDiscountPrice());
                Integer goodsNum = (null == orderGoods.getDeliveredNum() ? 0 : orderGoods.getDeliveredNum());
                orderTotalAmount += price * goodsNum;
                // 更新orderGoods的收货数量
                orderGoods.setReceivedNum(goodsNum);
            }
        }
    }

    if (!validDeliveryCount) {
        throw new BusinessException(“订单号:" + order.getOrderNo() + ",订单下所有商品都已发货才可进行签收操作,请确认。");
    }

    order.setOrderStatus(Integer.valueOf(StatusEnum.ORDER_STATUS.ORDER_SIGN.getCode()));
    order.setOrderTotalAmount(orderTotalAmount);
    order.setPaymentAmount(orderTotalAmount);
    order.setUnpaidAmount(orderTotalAmount);
}

 

你可以发现这段单纯实现业务规则的代码,会更加的简单、清晰,也会使软件更加的容易维护。在DDD的方法论里面,业务规则是在领域层来实现的,领域层的代码仅仅是业务规则,这时候,其分层架构的分层逻辑和基于贫血模型的分层逻辑也会不一样了。

通过以上代码的对比我们发现:

  • 剥离业务规则无关的代码,将更加清晰简单,容易和业务规则保持一致。
  • 贫血模型会导致业务逻辑层混杂了太多代码和逻辑,难以还原业务规则,保证代码与设计一致性,是复杂性根源。

3 DDD如何解决软件复杂性

DDD解决软件复杂性的方法核心为两点:

  • 通过领域模型为业务知识建模,领域模型作为业务、技术团队沟通的统一语言。
  • 确保软件实现与领域模型保持一致。

软件实现与领域模型保持一致是本书的核心思想,DDD构建了一套完整的方法论来支持领域模型驱动程序设计。这套方法论简述如下。

  • 分层架构:业务规则的代码只占软件很少的代码却是最核心的部分代码,将其分离出来作为独立的领域层,使领域层的实现与领域模型保持一致,领域层的业务对象不再是贫血模型。
  • 领域驱动设计:领域驱动设计,即领域模型驱动程序设计。这里给出了如何通过代码表达领域模型的编码模式。这些模式包括:关联、实体、值对象、服务、聚合根、Repository、Factory。它们构建了将领域模型表达成代码的方法论,保证了代码和设计一致。
  • 战略设计:复杂领域模型的实现方法论。

我将在下一篇文章中详细解释DDD的核心思想,让你明白它是如何解决复杂性的。


注:www2014.aspxhtml.com转载自cnblogs,若看不到图片,请移步来源网址查看。
via:https://www.cnblogs.com/baihmpgy/p/10259264.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注