在Java中如何设计领域对象模型_Java业务建模解析_技术教程

DDD在Java中落地的核心是让领域对象承载业务语义：封装行为而非仅数据，值对象不可变且重写equals/hashCode，聚合根明确边界并隔离持久化细节。

Domain-Driven Design（DDD）在 Java 中落地，核心不是堆砌注解或套用框架，而是让对象真正承载业务语义。领域对象模型不是数据库表的镜像，也不是 DTO 的变体，它得能回答“这个对象能做什么”“它什么时候是合法的”“它的状态如何被改变”。

领域对象必须封装行为，不能只有 getter/setter

很多团队把 Order 类写成纯数据容器：一堆 private 字段 + public getter/setter。这导致业务逻辑散落在 OrderService 里，Order 自身无法表达“订单可以取消”“已发货的订单不能改地址”这类规则。

正确做法是把校验和状态变更逻辑收进领域对象内部：

public class Order {
    private OrderStatus status;
    private Address shippingAddress;

    public void changeShippingAddress(Address newAddress) {
        if (status == OrderStatus.SHIPPED) {
            throw new IllegalStateException("Cannot modify address after shipment");
        }
        this.shippingAddress = newAddress;
    }

    public void cancel() {
        if (status == OrderStatus.CANCELLED) return;
        if (status == OrderStatus.SHIPPED) {
            throw new IllegalStateException("Shipped order cannot be cancelled");
        }
        this.status = OrderStatus.CANCELLED;
    }
}

关键点：

changeShippingAddress() 和 cancel() 是命令方法，不是 setter；它们隐含前置条件与副作用
字段保持 private，不暴露 setStatus() 这类危险接口
构造函数应强制满足基本不变量（如 orderId 非空、创建时间必设）

值对象（Value Object）要不可变且重写 equals/hashCode

像 Money、Address、PhoneNumber 这类对象，本质是“值”，不是“身份”。Java 中常见错误是把它做成可变类，或直接用 String 代替。

例如：Address 若可变，两个订单共用同一 Address 实例，一处改了街道，另一处也跟着变——这不是业务事实，是 bug。

正确实现要点：

所有字段 final，构造后不可变
不提供 setter，也不暴露可变集合（如返回 Collections.unmodifiableList()）
必须重写 equals() 和 hashCode()，基于字段内容比较（IDE 可自动生成）
推荐使用记录类（record）简化： public record Address(String street, String city, String zipCode) {}