微服务/DDD架构下product与seo表1:1关系最优存储方案咨询

首先直接排除方案1（双向存储对方ID）：

• 该方案没有任何收益，反而会引入额外的数据一致性风险：关联关系变更时需要同时更新两张表，任意一侧更新失败都会出现两边ID不匹配的脏数据，还会额外增加事务维护成本，完全违反DDD尽量减少双向依赖的设计原则。

方案2和方案3的选择完全取决于你的业务场景和限界上下文划分： #

选择方案2（仅product表存seo_id）的适用场景 #

• SEO属于商品域的内置能力，和产品强绑定，产品删除时SEO也会同步废弃
• 核心查询路径是从产品侧出发关联查询SEO：比如商品详情页渲染、商品上架审核流程中，都是先查询产品基础信息，再关联拉取对应的SEO配置
• 这种设计下Product作为商品域的聚合根，持有SEO实体的引用，符合DDD聚合根管理内部关联对象的规则。

-- 对应建表语句
CREATE TABLE product (
  id UUID DEFAULT uuid_generate_v4(),
  seo_id UUID,
  PRIMARY KEY (id)
)

CREATE TABLE seo (
  id UUID DEFAULT uuid_generate_v4(),
  PRIMARY KEY (id)
)

选择方案3（仅seo表存product_id）的适用场景 #

• SEO是独立的通用域能力，后续需要支持文章、活动、分类页等其他类型资源的SEO配置
• 核心查询路径是从SEO侧出发关联查询所属资源：比如SEO运营后台按关键词、排名筛选SEO配置后，需要关联展示对应资源的基础信息（比如产品的上下架状态、库存）
• 该方案可扩展性更强，只需要在seo表中新增resource_type字段标注关联资源类型，就可以复用这套表结构支持所有资源的SEO存储，不需要改造其他业务表。

-- 对应建表语句（可扩展版本）
CREATE TABLE product (
  id UUID DEFAULT uuid_generate_v4(),
  PRIMARY KEY (id)
)

CREATE TABLE seo (
  id UUID DEFAULT uuid_generate_v4(),
  product_id UUID,
  resource_type INT DEFAULT 1 COMMENT '1=商品,2=文章,3=活动页',
  PRIMARY KEY (id)
)

额外优化建议 #

如果两个实体属于同一个限界上下文，且没有单独操作SEO的独立业务场景，完全可以直接把SEO的标题、描述等字段合并到product表中，1:1强关联场景下拆分表反而会增加不必要的关联查询开销。

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