领域实体Account的代码建模：状态变更与相等性实现最佳方案

我熟悉DDD（领域驱动设计）及Entity（实体）的概念。根据DDD的定义，Entity是本质上由其唯一标识所定义的对象。在我的项目中，已确定Account为一个Entity，在代码中会以包含标识字段的类来表示，示例代码如下：

class Account { 
    private Id id; 
    private AccountStatus status; 
    // ... 其他字段
}

由于Account是Entity，其生命周期内除Id字段外，其余所有字段的状态均可发生变更。

我的核心问题是：在状态变更与对象相等性这两个维度上，如何以最佳方式在代码中对该Entity进行建模？

1. 状态变更维度：既然实体的状态会随时间发生变化，那么该类应建模为可变类，还是每次状态变更时创建新引用的不可变类？
2. 对象相等性维度：由于Account仅通过Id来唯一标识，equals方法是否应仅比较对象的Id？若考虑所有字段或不考虑任何字段，分别存在哪些潜在问题？

一、状态变更维度：可变类 vs 不可变类 #

这没有绝对的“标准答案”，得结合你的业务场景和团队开发习惯来选择，我结合实践给你梳理两种方案的适用场景和利弊：

1. 可变类（直接修改字段） #

• 适用场景：当Account的状态变更频繁，且变更逻辑紧密依赖当前状态时，可变类会更贴合业务思维。比如用户修改账户昵称、激活/冻结账户这类操作，直接在原对象上调用updateNickname()、activateAccount()这类方法，代码可读性拉满，团队上手也快。
• 优势：避免频繁创建新对象带来的内存开销，逻辑流程和业务操作一一对应，直观易懂。
• 注意事项：一定要做好封装和线程安全！所有状态变更必须通过实体内部的方法完成（不要让外部直接修改字段），比如不能让外部直接设置status，而是调用activateAccount()，在方法里先判断当前状态是否允许激活，再修改字段；如果是多线程环境，要加锁或者用线程安全的字段类型。

2. 不可变类（每次变更创建新实例） #

• 适用场景：当业务需要追踪状态变更历史，或者项目采用函数式编程风格时，不可变类是更好的选择。比如账户的每一次状态变更都需要留痕，创建新实例可以轻松保留历史版本；而且不可变对象天然线程安全，不用操心并发问题。
• 优势：线程安全无副作用，状态变更轨迹清晰，容易实现快照、回滚等功能。
• 注意事项：频繁创建新对象可能会带来轻微的GC压力，但在绝大多数业务场景下这个影响可以忽略；另外要保证所有字段都是不可变的（比如用final修饰，集合类型用不可变集合），避免内部状态被意外修改。

总结：如果更关注实体的当前状态、变更逻辑简单直接，选可变类；如果需要追踪状态历史、追求线程安全或者适配函数式风格，选不可变类。很多时候我们会混合使用：核心业务逻辑用可变类保证效率和可读性，需要记录历史时把可变实体转换成不可变快照对象。

二、对象相等性维度：equals方法的实现策略 #

根据DDD的核心原则，实体的相等性必须由唯一标识（Id）来判断，这是毫无疑问的，下面分析不同实现方式的问题：

1. 仅比较Id字段（强烈推荐） #

• 符合DDD定义：实体的本质是其唯一标识，不管状态怎么变，只要Id相同，就是同一个Account。比如同一个账户昨天是INACTIVE，今天变成ACTIVE，它还是同一个账户，equals应该返回true。
• 避免的坑：不会因为状态变更导致相等性变化，这在集合操作里特别重要。比如把Account放到HashSet里，状态变更后，基于Id计算的hashCode不会变，不会出现找不到对象的情况。
• 实现示例：

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Account account = (Account) o;
    return Objects.equals(id, account.id);
}

@Override
public int hashCode() {
    return Objects.hash(id);
}

2. 比较所有字段（不推荐） #

• 潜在问题：状态变更后equals结果会变化，完全违背实体的定义。比如同一个账户修改了昵称后，原来在集合里的对象就找不到了；而且字段越多，equals和hashCode的维护成本越高，容易出错。
• 例外：这是值对象（Value Object）的相等性判断方式，但Account是实体，绝对不要这么做。

3. 使用默认的Object.equals（不推荐） #

• 潜在问题：默认equals比较的是对象引用，这意味着即使两个对象Id完全相同，只要是不同实例，equals就返回false。比如从数据库加载的Account和内存里的同一个账户实例，会被当成不同对象，业务逻辑会彻底混乱。

总结：严格按照唯一标识Id实现equals和hashCode，这是DDD实体建模的核心规则，能避免大量潜在的业务bug。

内容的提问来源于stack exchange，提问作者abhijeetpawar