别再被VO、BO、PO、DTO、DO绕晕？代码一讲就懂！

大家好，我是晓凡。 前阵子晓凡的粉丝朋友面试，被问到“什么是VO？和DTO有啥区别？” 粉丝朋友：“VO就是Value Object，DTO就是Data Transfer Object……” 面试官点点头：“那你说说，一个下单接口里，到底哪个算VO，哪个算DTO？” 粉丝朋友有点犹豫了。 回来后粉丝朋友痛定思痛，把项目翻了个底朝天，并且把面试情况告诉了晓凡，下定决心捋清楚了这堆 XO 的真实含义。 于是乎，这篇文章就来了 今天咱们就用一段“用户下单买奶茶”的故事，把 VO、BO、PO、DTO、DO 全部聊明白。看完保准你下次面试不卡壳，写代码不纠结。 一、先放结论 它们都是“为了隔离变化”而诞生的马甲 缩写 英文全称 中文直译 出现位置 核心目的 PO Persistent Object 持久化对象 数据库 ↔ 代码 一张表一行记录的直接映射 DO Domain Object 领域对象 核心业务逻辑层 充血模型，封装业务行为 BO Business Object 业务对象 应用/服务层 聚合多个DO，面向用例编排 DTO Data Transfer Object 数据传输对象 进程/服务间 精简字段，抗网络延迟 VO View Object 视图对象 控制层 ↔ 前端 展示友好，防敏感字段泄露 一句话总结： PO 管存储，DO 管业务，BO 管编排，DTO 管网络，VO 管界面。 下面上代码，咱们边喝奶茶边讲。 二、业务场景 用户下一单“芋泥波波奶茶” 需求： 用户选好规格（大杯、少冰、五分糖）。 点击“提交订单”，前端把数据发过来。 后端算价格、扣库存、落库，返回“订单创建成功”页面。 整条链路里，我们到底需要几个对象？ 三、从数据库开始：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 是“有血有肉的对象”，它把业务规则写成方法，让代码自己说话。