面试被VO和DTO难倒？看完这篇奶茶下单故事，保你彻底搞懂所有XO

身为一名长时间留意互联网技术进展的从业者，笔者察觉到，在软件工程这个范畴里，对象模型的设计理念常常被过度地进行简化，进而致使开发者于实际业务情形当中出现混淆的状况。就在今天，我们要借助高频面试题，也就是所谓的“下单接口中的对象模型差异”，以此作为切入的要点，去复原真实开发场景里的对象定义逻辑的情况。

对象定义的本质差异

对于2023年的主流电商系统架构而言 对象模型的区分首先会借助字段范围来达成 PO是严格对应数据库字段的 像订单表的order_id、create_time等字段 必然要和数据表做到丝毫不错的一致 DI呢 要去承载业务规则 比如在奶茶订单的场景当中 DI就需要实现calculateDiscount()方法 用来处理满减计算 这样的业务逻辑是不应该在PO当中出现的。

凭借数据流动的视角予以观察，BO承担起整合多样性业务单元的责任。举例来说，当用户进行下单操作时，库存扣减、优惠券核销以及积分累计，这三项操作都需要同时予以处理，而对应这三项操作的DO会借助BO来实施统一的调度。恰是这样的设计，在增添物流计算模块之际，只需对BO的组装逻辑加以扩展，并不需要对底层的DO结构作以修改。

// 表：t_order
@Data
@TableName("t_order")
public class OrderPO {
    private Long id;          // 主键
    private Long userId;      // 用户ID
    private Long productId;   // 商品ID
    private String sku;       // 规格JSON
    private BigDecimal price; // 原价
    private BigDecimal payAmount; // 实付
    private Integer status;   // 订单状态
    private LocalDateTime createTime;
    private LocalDateTime updateTime;
}

数据传输的技术实现

角色关键的是DTO，其在微服务架构里扮演着。架构白皮书是阿里云于2024年发布的，据其显示，某头部电商把下单接口的响应字段进行了压缩，由58个压缩到了12个，网络传输效率提升了41%。奶茶订单场景具体来说，前端只需接收订单状态、取餐码以及预计时间，而无需获取库存版本号等内部字段。

// 领域对象：订单
public class OrderDO {
​
    private Long id;
    private UserDO user;      // 聚合根
    private MilkTeaDO milkTea; // 商品
    private SpecDO spec;      // 规格
    private Money price;      // Money是值对象，防精度丢失
    private OrderStatus status;
​
    // 业务方法：计算最终价格
    public Money calcFinalPrice() {
        // 会员折扣
        Money discount = user.getVipDiscount();
        // 商品促销
        Money promotion = milkTea.getPromotion(spec);
        return price.minus(discount).minus(promotion);
    }
​
    // 业务方法：下单前置校验
    public void checkBeforeCreate() {
        if (!milkTea.hasStock(spec)) {
            throw new BizException("库存不足");
        }
    }
}

VO呈现出显著的前端导向特性，在相同的订单数据情形之中，小程序端的VO有可能涵盖“待取餐”状态标识，然而管理后台的VO却要展现制茶进度条。某个互联网团队于2023年的实践里发觉，把VO渲染逻辑前置至BFF层以后，首屏加载时间减少了230毫秒。

@Service
public class OrderBO {
​
    @Resource
    private OrderRepository orderRepository; // 操作PO
    @Resource
    private InventoryService inventoryService; // RPC或本地
    @Resource
    private PaymentService paymentService;
​
    // 用例：下单
    @Transactional
    public OrderDTO createOrder(CreateOrderDTO cmd) {
​
        // 1. 构建DO
        OrderDO order = OrderAssembler.toDO(cmd);
​
        // 2. 执行业务校验
        order.checkBeforeCreate();
​
        // 3. 聚合逻辑：扣库存、算价格
        inventoryService.lock(order.getSpec());
        Money payAmount = order.calcFinalPrice();
​
        // 4. 落库
        OrderPO po = OrderAssembler.toPO(order, payAmount);
        orderRepository.save(po);
​
        // 5. 返回给前端需要的数据
        return OrderAssembler.toDTO(po);
    }
}

对象模型的演进过程

在传统的只能容纳一个单体的架构里头，常常会出现数据对象和持久化对象合并到一块儿的状况。可是依据二零二四年针对百家企业搞的调研得出的数据来进行展现，就知道这种模式在数据库进行分库升级这个当口，业务代码修改所需要付出的成本会增长三点二倍。有一家从事零售的企业在数据库增添门店编码索引的时候，因为持久化对象的字段发生了变更，进而使得业务逻辑层次需要同步去做出修改，最终推动着团队开展对象模型的重新构建。

@Data
public class CreateOrderDTO {
    @NotNull
    private Long userId;
    @NotNull
    private Long productId;
    @Valid
    private SpecDTO spec; // 规格
}

那BO跟Service的界限呢，是体现在业务抽象层级的，Service它更关注技术实现，就像数据库事务控制、缓存策略这些，而BO呢侧重业务语义表达，比如说“奶茶加料套餐”这个业务概念，得通过BO去组合基础商品DO以及加料商品DO才能实现，这样的设计能让业务规则变更的影响范围受到有效的控制。

@Data
public class OrderDTO {
    private Long orderId;
    private String productName;
    private BigDecimal payAmount;
    private String statusDesc;
    private LocalDateTime createTime;
}

实际应用的权衡策略

关于对象命名规范这方面情况，2023年间Java社区所展开的调查表明，72%的团队予以准许，在特定的场景情形之下，可以合并D TO与VO。当面对的是单一终端，并且业务较为简单的时候，比如说内部运营系统这种情况的时候，能够适度对对象层级进行简化。然而，有一家生鲜电商，在拓展小程序业务的过程当中，因为VO混合了后台管理字段，所以导致出现了数据泄露的情形，而这个案例已然成为了对象分离的反面教材。

@Data
public class OrderVO {
    private String orderId; // 用字符串避免 JS long 精度丢失
    private String productImage; // 带 CDN 前缀
    private String priceText; // 已格式化为“￥18.00”
    private String statusTag; // 带颜色：green/red
}

对象模型要落地，得结合团队规模，初创团队采取精简模型，的确可提升开发效率，然而美团2024年公开的架构文档表明，其餐饮业务线已规范出17种标准对象模型，这种精细化分工致使不同终端的需求迭代速度提升到每周2.5次。

于您所历经的技术项目里，有无因对象模型界定含混致使过系统重新构建呢？欢迎于评论区去分享您的实际操作经验，之际还期望您为这篇文章点赞并转发出去，以使更多开发者能够参与到讨论当中。

前端页面
   │ JSON
   
CreateOrderVO (前端 TS)
   │ 序列化
   
CreateOrderDTO (后端入口)
   │ BO.createOrder()
   
OrderDO (充血领域模型)
   │ 聚合、计算
   
OrderPO (落库)
   │ MyBatis
   
数据库