别再被VO、BO、PO、DTO、DO绕晕！今天用一段代码把它们讲透

整条链路里，我们到底需要几个对象？

三、从数据库开始：PO

PO是Persistent Object的简写 PO 就是“一行数据一个对象”，字段名、类型和数据库保持一一对应，不改表就不改它。

// 表：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;

}

注意：PO 里绝不能出现业务方法，它只是一个“数据库搬运工”。

四、核心业务：DO

DO 是“有血有肉的对象”，它把业务规则写成方法，让代码自己说话。

// 领域对象：订单
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("库存不足");

        }

    }

}

DO 可以引用别的 DO，形成聚合根。它不关心数据库，也不关心网络。

五、面向用例：BO

BO 是“场景大管家”，把多个 DO 攒成一个用例，常出现在 Service 层。

@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);

    }

}

BO 的核心是编排，它把 DO、外部服务、PO 串成一个完整的业务动作。

六、跨进程/服务：DTO

DTO 是“网络快递员”，字段被压缩成最少，只带对方需要的数据。

1）入口 DTO：前端 → 后端

@Data
public class CreateOrderDTO {

    @NotNull

    private Long userId;

    @NotNull

    private Long productId;

    @Valid

    private SpecDTO spec; // 规格

}

2）出口 DTO：后端 → 前端

@Data
public class OrderDTO {

    private Long orderId;

    private String productName;

    private BigDecimal payAmount;

    private String statusDesc;

    private LocalDateTime createTime;

}

DTO 的字段命名常带 UI 友好词汇（如 statusDesc），并且绝不暴露敏感字段（如 userId 在返回给前端时可直接省略）。

七、最后一步：VO

VO 是“前端专属快递”，字段可能二次加工，甚至带 HTML 片段。

@Data
public class OrderVO {

    private String orderId; // 用字符串避免 JS long 精度丢失

    private String productImage; // 带 CDN 前缀

    private String priceText; // 已格式化为“￥18.00”

    private String statusTag; // 带颜色：green/red

}

VO 通常由前端同学自己写 TypeScript/Java 类，后端只负责给 DTO，再让前端 BFF 层转 VO。如果你用 Node 中间层或 Serverless，VO 就出现在那儿。

八、一张图记住流转过程

前端页面

   │ JSON

   ▼
CreateOrderVO (前端 TS)

   │ 序列化

   ▼
CreateOrderDTO (后端入口)

   │ BO.createOrder()

   ▼
OrderDO (充血领域模型)

   │ 聚合、计算

   ▼
OrderPO (落库)

   │ MyBatis

   ▼

数据库

返回时反向走一遍：

数据库

   │ SELECT

OrderPO

   │ 转换

OrderDTO

   │ JSON
OrderVO (前端 TS 渲染)

九、常见疑问答疑

0. 为什么 DO 和 PO 不合并？ 数据库加索引、加字段不影响业务；业务改规则不改表结构。隔离变化。
1. DTO 和 VO 能合并吗？ 小项目可以，但一上微服务或多端（App、小程序、管理后台），立马爆炸。比如后台需要用户手机号，App 不需要，合并后前端会拿到不该看的数据。
2. BO 和 Service 有什么区别？ BO 更贴近用例，粒度更粗。Service 可能细分读写、缓存等。命名随意，关键看团队约定。

十、一句话背下来

数据库里叫 PO，业务里是 DO，编排靠 BO，网络走 DTO，前端看 VO。

下次面试官再问，你就把奶茶故事讲给他听，保证他频频点头。

本期内容到这儿就结束了

我是晓凡，再小的帆也能远航

我们下期再见 ヾ(•ω•`)o (●'◡'●)