数据建模实操指南：从领域模型到数据库表的无损映射

在面向对象分析与设计的全链路中，数据建模是连接抽象领域模型与具体技术实现的关键桥梁。其核心任务是将业务对象——实体、值对象、聚合——精准地转化为可持久化的数据库表结构。然而，实践中常见的问题是建模与建表脱节，比如将值对象拆成独立表、聚合边界与表结构不一致、字段类型随意选型，最终导致业务语义丢失、数据冗余、事务不一致和系统扩展困难。

实现“无损映射”的核心，在于坚持“业务语义优先、结构对齐、约束一致”。这意味着数据库表不仅存储数据，更应准确反映领域模型的实体关系、业务规则与边界约束，达到“表结构能反推领域模型，领域模型能直接落地为表”的理想状态。本文将以电商订单领域为例，系统拆解六大核心映射规则、四类对象的映射方案，并提供可直接套用的实战SQL与评审清单，助力开发团队实现从领域模型到数据库表的零损耗转化。

数据建模映射的四个核心原则

映射的本质并非简单的“字段对应”，而是“业务语义的持久化”。在着手设计表结构前，必须坚守以下原则：

1. 业务语义优先：表名、字段名、约束条件必须紧密贴合领域模型的业务含义。例如，使用 order_status 而非模糊的 status，使用 receive_address_province 而非宽泛的 province。
2. 结构对齐原则：领域模型的对象结构决定表结构。实体映射为独立表，值对象嵌入为字段或组合字段，聚合映射为“主表+子表”，不破坏原有的对象组织方式。
3. 约束一致原则：领域模型中定义的业务规则，如唯一标识、非空、状态枚举，必须转化为数据库层面的约束，如主键、唯一索引、非空约束和外键。
4. 可扩展原则：在设计时为合理的业务变化预留空间。例如，选择不过于窄的字段类型，为状态枚举预留编码，以避免未来频繁修改表结构。

数据建模的六个映射规则

规则一：表名/字段名 = 领域对象名/属性名（语义一致）

• 表名：通常使用实体名的复数形式（如 Order → order, OrderItem → order_item）。建议直接使用业务语义名，避免 tb_order、t_order 等技术前缀。
• 字段名：采用下划线命名法，将属性名直接转化（如 orderId → order_id）。对于属于特定对象的属性，可使用前缀区分（如 receive_address 相关字段），避免不同对象间的同名字段产生混淆。
• 禁用模糊命名：避免使用 data、info、content 等无明确业务含义的字段名。字段名应能直接体现其业务角色，例如使用 total_amount 而非笼统的 amount。

规则二：实体 = 独立表，唯一标识 = 主键（身份一致）

领域模型中的实体（具有唯一ID和生命周期）必须映射为独立的数据表。实体的唯一标识（如 order_id, user_id）应优先作为数据库的主键，而不是默认使用无业务含义的自增 id。

• 主键策略：优先选择具有业务意义的唯一标识（如订单号 order_no、用户手机号 mobile），或在无合适业务标识时使用 UUID。
• 自增ID场景：仅在确实没有天然业务唯一标识时使用自增ID（如 order_item_id）。但此时必须通过唯一索引来约束实体的业务唯一标识，例如 UNIQUE KEY idx_order_no (order_no)。

规则三：值对象 = 嵌入式字段 / 组合字段（不独立建表）

值对象（没有唯一ID，依附于实体存在）禁止独立建表。它们应该嵌入到所属实体的表中，通过“前缀+属性名”或JSON字段进行存储。

• 简单值对象：例如 Money（包含 currency 和 amount），可拆分为多个字段：money_currency, money_amount。
• 复杂值对象：例如 ReceiveAddress（包含省、市、区、详细地址等），可拆分为多个字段，或使用一个JSON字段来保持其结构的完整性。

规则四：聚合 = “主表 + 子表”，子表外键关联聚合根主键（边界一致）

聚合是领域中的“最小事务单元”，在数据库中应映射为“主表（聚合根）+ 子表（聚合内实体）”的结构。

• 主表：对应聚合根实体（如 order 表）。
• 子表：对应聚合内的其他实体（如 order_item 表）。
• 关联规则：子表必须通过外键关联到主表的主键（如 order_item.order_id 关联 order.order_id）。此外，外键通常应设置为 ON DELETE CASCADE（级联删除），以确保删除聚合根时，其内部所有实体能被一并删除，维护聚合的完整性。
• 约束：子表不应有除聚合根以外的其他对外关联，即子表的外键只能指向聚合根所在的主表。

规则五：关联关系 = 外键 / 中间表（关系一致）

领域模型中实体间的关联关系，需按以下规则映射到数据库：

关联类型	领域场景示例	映射方案	约束条件
一对一	用户 - 用户详情 (User-UserProfile)	方案1：详情表外键关联用户表主键（推荐）<br>方案2：共享主键	外键需添加唯一约束 (UNIQUE KEY)
一对多	订单 - 订单项 (Order-OrderItem)	子表（订单项）通过外键关联主表（订单）的主键	外键非空，通常设置级联删除
多对多	用户 - 角色 (User-Role)	新增中间表（如 user_role），存储双方实体的主键	使用联合主键 (user_id+role_id)，或单独主键加联合唯一索引

规则六：业务规则 = 数据库约束（约束一致）

领域模型定义的业务规则必须转化为数据库约束，从底层保证数据一致性。

• 非空约束：核心属性（如 order.order_id, order.total_amount）必须设为 NOT NULL。
• 唯一约束：业务上要求唯一的属性（如订单号、手机号）必须设为 UNIQUE KEY。
• 枚举约束：状态类属性（如 order_status）应使用 ENUM 或 TINYINT 存储，并配合 CHECK 约束或应用层代码限制取值范围。
• 长度约束：字符串字段应根据业务实际长度设置，例如手机号 mobile 设为 VARCHAR(11)，订单号 order_id 设为 VARCHAR(64)，而非盲目使用 VARCHAR(255)。

四类核心对象映射方案详解（附SQL）

掌握面向对象设计模式与领域建模思想后，将其落地到数据库是关键一步。以下是具体的映射实践。

1. 实体映射：独立表 + 主键 + 约束

领域模型：Order 实体（聚合根）
核心属性包括：orderId（唯一标识）、userId、status（订单状态枚举）、totalAmount（Money值对象）、receiveAddress（值对象）、createTime、expireTime。

映射方案：创建独立的 order 表，并将值对象的属性嵌入为表中的字段。

CREATE TABLE `order` (
  `order_id` varchar(64) NOT NULL COMMENT '订单号（实体唯一标识，主键）',
  `user_id` bigint NOT NULL COMMENT '用户ID（关联用户表）',
  `order_status` tinyint NOT NULL COMMENT '订单状态：0=未支付，1=已支付，2=已取消，3=已完成',
  -- 嵌入Money值对象（货币+金额）
  `total_currency` varchar(3) NOT NULL DEFAULT 'CNY' COMMENT '货币类型（值对象属性）',
  `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额（值对象属性）',
  -- 嵌入ReceiveAddress值对象（拆分为多个字段）
  `receive_province` varchar(32) NOT NULL COMMENT '收货省份',
  `receive_city` varchar(32) NOT NULL COMMENT '收货城市',
  `receive_district` varchar(32) NOT NULL COMMENT '收货区县',
  `receive_detail` varchar(255) NOT NULL COMMENT '详细地址',
  `receive_mobile` varchar(11) NOT NULL COMMENT '收货手机号',
  `receive_name` varchar(64) NOT NULL COMMENT '收货人',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `expire_time` datetime NOT NULL COMMENT '超时时间',
  `update_time` datetime NOT NULL COMMENT '更新时间',
  PRIMARY KEY (`order_id`), -- 业务唯一标识作为主键
  KEY `idx_user_id` (`user_id`),
  KEY `idx_create_time` (`create_time`),
  -- 业务规则约束：订单状态只能是枚举值
  CHECK (`order_status` IN (0,1,2,3)),
  -- 关联用户表外键（根据实际架构需求决定是否添加）
  CONSTRAINT `fk_order_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表（聚合根主表）';

2. 值对象映射：嵌入式字段（禁止独立建表）

领域模型：ReceiveAddress 值对象（无ID、不可变、依附于Order）
核心属性：province、city、district、detailAddress、mobile、receiverName。

映射方案：如上一节所示，将值对象的每个属性拆分为带前缀（receive_）的字段，嵌入 order 表中。

替代方案：JSON字段存储（适用于复杂值对象）
如果值对象属性较多或结构复杂，可以考虑使用 JSON 类型字段存储，以保持其结构完整性。

-- 简化版：用JSON字段存储ReceiveAddress值对象
ALTER TABLE `order` ADD COLUMN `receive_address` json NOT NULL COMMENT '收货地址（值对象，JSON格式）';

-- JSON字段示例值：
{
  "province": "广东省",
  "city": "深圳市",
  "district": "南山区",
  "detailAddress": "科技园路1号",
  "mobile": "13800138000",
  "receiverName": "张三"
}

• 适用场景：值对象属性多、修改频率低、且不需要对值对象内的单个属性进行独立查询或建索引。
• 注意：查询时需使用MySQL的JSON函数（如JSON_EXTRACT），且无法直接为值对象内的属性创建独立索引。

3. 聚合映射：主表 + 子表（外键关联 + 级联约束）

领域模型：Order 聚合（包含 Order聚合根、OrderItem实体、ReceiveAddress值对象）
映射方案：order 表作为主表，order_item 表作为子表，子表通过外键 order_id 关联主表，并设置级联删除。

CREATE TABLE `order_item` (
  `order_item_id` bigint NOT NULL AUTO_INCREMENT COMMENT '订单项ID（自增，无业务含义）',
  `order_id` varchar(64) NOT NULL COMMENT '订单号（关联聚合根主表）',
  `product_id` bigint NOT NULL COMMENT '商品ID',
  `product_name` varchar(128) NOT NULL COMMENT '商品名称',
  `product_price` decimal(10,2) NOT NULL COMMENT '商品单价',
  `quantity` int NOT NULL COMMENT '购买数量',
  `sub_total_amount` decimal(10,2) NOT NULL COMMENT '订单项小计金额',
  PRIMARY KEY (`order_item_id`),
  -- 外键关联聚合根主表，并设置级联删除
  CONSTRAINT `fk_order_item_order` FOREIGN KEY (`order_id`) REFERENCES `order` (`order_id`) ON DELETE CASCADE,
  -- 联合唯一索引：防止同一订单中重复添加同一商品
  UNIQUE KEY `idx_order_id_product_id` (`order_id`,`product_id`),
  KEY `idx_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单项表（订单聚合子表）';

• 核心约束：ON DELETE CASCADE 保证了聚合的完整性。删除一个订单时，其下所有订单项会被自动删除，避免产生“孤儿数据”。
• 边界控制：order_item 表只应关联其聚合根 order 表，不应直接关联 product 表以外的其他表。任何外部访问都应通过聚合根 order 进行。

4. 关联关系映射：外键 / 中间表

一对多关联已在上述聚合映射中体现。

多对多关联示例（User ↔ Role）

-- 用户表
CREATE TABLE `user` (
  `user_id` bigint NOT NULL COMMENT '用户ID（主键）',
  `mobile` varchar(11) NOT NULL COMMENT '手机号（唯一）',
  `user_name` varchar(64) NOT NULL COMMENT '用户名',
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `idx_mobile` (`mobile`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

-- 角色表
CREATE TABLE `role` (
  `role_id` bigint NOT NULL COMMENT '角色ID（主键）',
  `role_name` varchar(32) NOT NULL COMMENT '角色名称（唯一）',
  `role_desc` varchar(255) DEFAULT NULL COMMENT '角色描述',
  PRIMARY KEY (`role_id`),
  UNIQUE KEY `idx_role_name` (`role_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表';

-- 多对多中间表（用户-角色关联）
CREATE TABLE `user_role` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
  `user_id` bigint NOT NULL COMMENT '用户ID',
  `role_id` bigint NOT NULL COMMENT '角色ID',
  PRIMARY KEY (`id`),
  -- 联合唯一约束：避免同一用户重复分配同一角色
  UNIQUE KEY `idx_user_role` (`user_id`,`role_id`),
  -- 外键关联，通常设置级联删除
  CONSTRAINT `fk_user_role_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE CASCADE,
  CONSTRAINT `fk_user_role_role` FOREIGN KEY (`role_id`) REFERENCES `role` (`role_id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户-角色关联表';

一对一关联示例（User → UserProfile）

CREATE TABLE `user_profile` (
  `profile_id` bigint NOT NULL AUTO_INCREMENT COMMENT '详情ID',
  `user_id` bigint NOT NULL COMMENT '用户ID（唯一，关联用户表）',
  `real_name` varchar(64) DEFAULT NULL COMMENT '真实姓名',
  `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号',
  `birthday` date DEFAULT NULL COMMENT '生日',
  PRIMARY KEY (`profile_id`),
  -- 唯一约束：确保一个用户只能有一个详情记录
  UNIQUE KEY `idx_user_id` (`user_id`),
  CONSTRAINT `fk_profile_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户详情表';

实战映射步骤与常见误区

可直接套用的五步映射法

1. 梳理领域模型结构：明确所有实体、值对象、聚合以及它们之间的关联关系（一对一、一对多、多对多）。
2. 拆分映射单元：规划每个实体、值对象、聚合和关联关系对应的数据库结构（独立表、嵌入字段、主表/子表、外键/中间表）。
3. 设计表结构细节：
   • 确定主键策略（业务ID / UUID / 自增ID）。
   • 进行字段类型选型（金额用DECIMAL，手机号用VARCHAR(11)，状态用TINYINT等）。
   • 添加所有必要的约束（主键、外键、唯一索引、非空、CHECK）。
4. 优化索引设计：根据实际查询场景（关联查询、过滤条件、排序字段）添加索引，同时避免过度索引影响写性能。
5. 验证无损性：尝试从设计好的表结构反向推导出领域模型，检查是否丢失了业务语义、关系是否一致、约束是否完整。

常见误区及修正方案

误区一：值对象独立建表

• 表现：为ReceiveAddress值对象创建独立的address表，并添加address_id主键，order表通过address_id关联。
• 问题：破坏了值对象的“依附性”和“不可变性”语义，增加事务复杂性，且地址本身并无独立生命周期。
• 修正：将值对象嵌入所属实体表，拆分为多个字段或用JSON字段存储。

误区二：聚合边界与表边界不一致

• 表现：将Order和PaymentRecord（支付记录，属于另一个聚合）合并到order表中。
• 问题：PaymentRecord有独立生命周期（一个订单可能多次支付），合并会导致数据冗余、更新复杂，破坏聚合的事务边界。
• 修正：将PaymentRecord识别为独立的Payment聚合，建立payment_record表，通过order_id与order表关联。

误区三：主键用自增ID替代业务唯一标识

• 表现：order表使用自增id作为主键，业务唯一标识order_no仅作为普通字段且无唯一约束。
• 问题：自增ID无业务含义，无法体现实体的全局唯一性，应用层容易产生重复订单数据。
• 修正：使用order_no作为主键；或采用“自增ID（主键）+ order_no（业务唯一键）”的组合。

误区四：字段类型选型随意

• 表现：金额total_amount使用FLOAT，创建时间create_time使用VARCHAR存储。
• 问题：FLOAT存在精度丢失风险，不适合金融计算；VARCHAR存储的时间无法高效排序和进行范围查询。
• 修正：金额使用DECIMAL(10,2)，时间使用DATETIME或TIMESTAMP，字符串根据实际业务长度使用VARCHAR(N)。

误区五：外键约束缺失

• 表现：order_item表没有order_id的外键约束，仅存储order_no字符串。
• 问题：无法保证数据引用完整性，删除订单后会产生“孤儿”订单项；基于字符串的关联查询效率较低。
• 修正：在子表中添加外键关联主表主键，并根据业务规则设置ON DELETE CASCADE或ON DELETE RESTRICT等级联规则。

总结

从领域模型到数据库表的无损映射，其核心并非机械的字段对应，而是业务规则、对象结构与边界约束的完整落地。一套优秀的表结构本身就是最好的“业务文档”，团队成员通过表名、字段名和约束就能清晰地理解核心业务逻辑。

请始终牢记：领域模型是源头，数据库表是结果，映射规则是桥梁。避免脱离领域模型凭空设计表结构，也不要为了追求“灵活”而牺牲业务语义的准确性。遵循本文阐述的六大规则与四类映射方案，团队能够有效地实现“领域模型→数据库表”的零损耗转化，为系统的编码实现、长期维护与平滑扩展奠定坚实的数据基础。在云栈社区的技术实践中，遵循这些原则的团队往往能构建出更清晰、更健壮的数据层。

参考资料

[1] 面向对象分析与设计 | 数据建模：从领域模型到数据库表的无损映射规则, 微信公众号：mp.weixin.qq.com/s/VQY8nISihDr0HeRqMbsZTQ

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。