订单对象设计需以Order为聚合根，仅持userId而非User全量对象；OrderItem只存productId等快照信息；集合用final List初始化并不可变；必须通过Builder模式创建，build()中校验必填项与金额一致性；订单号应采用时间戳+机器标识+序列号组合生成；组合子对象须不可变并提供深拷贝copy()方法；金额计算统一用BigDecimal指定HALF_UP舍入。
订单对象设计要先明确聚合根
订单是典型的聚合根，Order 必须持有对 OrderItem、Address、PaymentInfo 的强引用，但不能直接持有 User 全量对象（避免循环依赖和领域污染）。常见错误是把 User 当作字段塞进 Order，结果序列化失败或 JPA 报 LazyInitializationException。
推荐做法：
-
Order仅保存userId（Long类型），必要时通过服务层查用户昵称等展示字段 -
OrderItem不持有Product实体，只存productId、skuCode、快照价格和数量 - 所有子对象用
final List<?>初始化，禁止外部直接修改集合引用
使用 Builder 模式控制订单创建入口
直接暴露 new Order(...) 构造会导致参数爆炸、必填项遗漏、状态不一致。必须用 Order.Builder 封装校验逻辑，比如：收货地址不能为空、至少含一个商品、总金额需与明细一致。
关键点：
立即学习“Java免费学习笔记（深入）”；
- Builder 的
build()方法内做终态校验，失败抛IllegalArgumentException - 不要在 Builder 中调用远程服务（如查库存），那属于应用服务职责
- Builder 实例应为非静态内部类，绑定到具体
Order类，避免跨领域复用混乱
public class Order {
private final Long orderId;
private final Long userId;
private final Address shippingAddress;
private final List<OrderItem> items;
private final BigDecimal totalAmount;
private Order(Builder builder) {
this.orderId = builder.orderId;
this.userId = builder.userId;
this.shippingAddress = builder.shippingAddress;
this.items = Collections.unmodifiableList(builder.items);
this.totalAmount = calculateTotal(builder.items);
validate();
}
public static class Builder {
private Long orderId;
private Long userId;
private Address shippingAddress;
private final List<OrderItem> items = new ArrayList<>();
public Builder setUserId(Long userId) { this.userId = userId; return this; }
public Builder setShippingAddress(Address address) { this.shippingAddress = address; return this; }
public Builder addItem(OrderItem item) { this.items.add(item); return this; }
public Order build() {
if (items.isEmpty()) throw new IllegalArgumentException("订单必须包含至少一个商品");
if (shippingAddress == null) throw new IllegalArgumentException("收货地址不能为空");
return new Order(this);
}
}
}
订单号生成必须全局唯一且可追溯
用 UUID.randomUUID().toString() 看似简单，但无法按时间排序、不便于运维排查。生产环境应采用「时间戳 + 机器标识 + 序列号」组合，例如 20240520153022-001-00047。
注意陷阱：
- 别在
Order构造时直接生成 ID —— 需要预留幂等场景（如前端重复提交） - 若用数据库自增主键，订单号不应直接等于
id，否则泄露业务量，且分库后难处理 - 建议单独抽离
OrderIdGenerator接口，实现类可基于 Redis 原子计数器或雪花算法
组合对象的深拷贝与状态隔离容易被忽略
订单创建后常需生成发票、通知、风控快照，这些操作会修改副本对象。如果直接 new Order(other) 或用 Lombok @Builder(toBuilder = true)，可能因 Address 或 OrderItem 是可变对象导致状态污染。
正确姿势：
- 所有组合子对象（
Address、OrderItem）必须是不可变类（final字段 + 无 setter） - 若需复制，每个子类提供自己的
copy()方法，对嵌套对象递归深拷贝 - 避免用
BeanUtils.copyProperties()—— 它绕过构造逻辑，丢失不可变性保障
最麻烦的其实是金额计算：小数必须用 BigDecimal，且所有加法必须指定 RoundingMode.HALF_UP 和精度（如 2 位），否则 0.1 + 0.2 != 0.3 会在订单总金额里暴露出来。
