多个地址应当作为Entity还是ValueObject？领域驱动设计相关疑问

首先明确核心判定：单个地址无论是否属于集合，都可以被定义为值对象。值对象的核心特征是无独立业务生命周期、仅通过属性相等性判断身份、不可变，和是否以集合形式作为实体属性没有关联。

针对存储的疑问，两种常用的合规方案如下：

• 方案1：单独建关联表，避免给地址分配独立业务ID
  不需要为地址表设置自增主键作为业务标识，仅通过user_id + 排序位（如address_order）的联合主键做数据库层面的行唯一约束。这个联合主键仅用于数据库存储的索引约束，不属于值对象的业务属性，完全不违反值对象的定义。
  读写时严格遵循值对象的不可变规则：当用户修改地址集合时，直接删除该用户关联的所有旧地址记录，再批量插入新的地址集合即可，不需要做单条地址的更新操作。
• 方案2：嵌入式存储，无需额外建表
  如果使用支持JSON/JSONB字段的关系型数据库（如PostgreSQL、MySQL 5.7+）或文档型数据库，可以直接将地址集合序列化后存储在用户表的单独字段中。这种方案天然不会生成地址的独立ID，完全匹配值对象作为用户实体属性的定位，实现成本更低。

如果后续业务出现需要地址独立复用（比如多个订单关联同一地址、单独统计地址使用数据）的需求，再将地址升级为实体即可，当前多地址注册的场景使用值对象完全满足要求。

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