Order、Item、Payment 三类即可实现核心流程，无需Spring或数据库；Order负责聚合计算并持有Item列表，不处理支付；Item封装单价与数量并校验合法性；Payment通过策略模式解耦支付渠道，职责分明且易于测试。
直接用 Order、Item、Payment 三个类就能跑通核心流程，不需要 Spring 或数据库——面向对象的关键是职责拆分，不是框架堆砌。
订单类 Order 只管聚合与计算，不碰支付逻辑
一个 Order 实例应该持有多个 Item，并提供 getTotalAmount() 和 add(Item item)。它不该有 pay() 方法，也不该知道微信还是支付宝——那是 Payment 的事。
-
Order的构造函数建议接受List或留空，避免强制传 null - 金额统一用
BigDecimal存储，别用double——比如0.1 + 0.2 != 0.3在结算里是硬伤 - 如果要支持优惠券，加个
setDiscount(BigDecimal discount)，但折扣计算仍由getTotalAmount()内部封装，不暴露中间变量
Item 类必须封装单价和数量，禁止裸露字段
别写 public double price 或 public int quantity。所有业务属性都得私有 + getter，且 getSubtotal() 应该返回 price.multiply(BigDecimal.valueOf(quantity))，而不是让外部拼接计算。
- 构造时校验
price.compareTo(BigDecimal.ZERO) > 0和quantity > 0，抛IllegalArgumentException - 不要在
Item里存“已打折后价格”——那是视图或结算快照的事，不是领域对象的职责 - 如果后续要扩展 SKU 或规格，把
name换成skuId字段更利于演进，现在先用字符串也行
支付行为交给独立的 Payment 类，用策略模式预留扩展点
别把微信支付参数硬编码进 Order。写一个接口 PaymentProcessor，再实现 WechatPaymentProcessor 和 MockPaymentProcessor（开发阶段用）。主流程调用 processor.process(order) 即可。
立即学习“Java免费学习笔记（深入）”；
- 实际调用前，检查
order.getTotalAmount().compareTo(BigDecimal.ZERO) > 0，否则直接拒绝，不走支付环节 - 支付成功后，
Payment类只负责返回boolean isSuccess()和String getTransactionId()，不修改Order状态——状态变更应由上层协调 - 日志里打印
order.getId()和processor.getClass().getSimpleName()，排查时能快速定位走的是哪个通道
最容易被忽略的是边界：空订单、单价为零的商品、高并发下重复提交——这些不在类图里，但在测试用例里必须覆盖。先写 OrderTest 验证加项、扣减、折扣逻辑，再写 PaymentTest 模拟成功/失败响应，比急着联调接口实在得多。
