DDD：如何领用领域驱动设计来避免写流水账代码

         过去一年里我们团队做了大量的老系统重构和迁移，其中有大量的代码属于流水账代码。通常能看到是开发在对外的API接口里直接写业务逻辑代码，或者在一个服务里大量的堆接口，导致业务逻辑实际无法收敛，接口复用性比较差。

        所以这讲主要想系统性的解释一下如何通过DDD的重构，将原有的流水账代码改造为逻辑清晰、职责分明的模块。

一、案例分析

举一个简单的常见案例：下单链路。

假设我们在做一个checkout接口，需要做各种校验、查询商品信息、 调用库存服务扣库存、然后生成订单：

 一个比较典型的代码，如下：

@RestController
@RequestMapping("/check")
public class CheckoutController {

    @Resource
    private ItemService itemService;
    @Resource
    private InventoryService inventoryService;
    @Resource
    private OrderRepository orderRepository;

    @PostMapping("checkout")
    public Result<OrderDO> checkout(Long itemId, Integer quantity) {
        // 1) Session管理
        Long userId = SessionUtils.getLoggedInUserId();
        if (userId <= 0) {
            return Result.fail("Not Logged In");
        }
        // 2）参数校验
        if (itemId <= 0 || quantity <= 0 || quantity >= 1000) {
            return Result.fail("Invalid Args");
        }
        // 3）外部数据补全
        ItemDO item = itemService.getItem(itemId);
        if (item == null) {
            return Result.fail("Item Not Found");
        }
        // 4）调用外部服务
        boolean withholdSuccess = inventoryService.withhold(itemId, quantity);
        if (!withholdSuccess) {
            return Result.fail("Inventory not enough");
        }
        // 5）领域计算
        Long cost = item.getPriceInCents() * quantity;
        // 6）领域对象操作
        OrderDO order = new OrderDO();
        order.setItemId(itemId);
        order.setBuyerId(userId);
        order.setSellerId(item.getSellerId());
        order.setCount(quantity);
        order.setTotalCost(cost);
        // 7）数据持久化
        orderRepository.createOrder(order);
        // 8）返回
        return Result.success(order);
    }
}

        这样的代码是不是非常熟悉呢？为什么这种典型的流水账代码在实际应用中会有问题？其本质问题是违背了SRP（Single Responsbility Principle）单一职责原则。

        这段代码里混杂了业务计算、校验逻辑、基础设施、和通信协议等，在未来无论哪一部分的逻辑变更都会直接影响到这段代码，长期当后人不断的在上面叠加新的逻辑时，会造成代码复杂度增加、逻辑分支越来越多，最终造成bug或者没人敢重构的历史包袱。