单库多表与多库多表对应单体与微服务两种物理边界

以薪资管理系统为例，员工管理与薪资结算分属员工上下文与薪资上下文，同一个员工Employee领域类可在两个上下文分别定义、体现为不同聚合。根据领域模型设计数据模型时，应为不同上下文的员工概念建立不同的员工表，并因限界上下文物理边界不同分两种方案：①进程内边界→单库多表：所有上下文共享同一数据库，各上下文的员工领域模型各自映射员工表、表间由共同员工ID关联，满足单体架构风格；②进程间边界→多库多表：为不同上下文建不同数据库，表定义与单库多表一致，符合微服务架构风格。无论采用哪种方案，领域模型几乎不受影响，唯一影响是ORM元数据需修改对库的映射；领域模型的代码结构不受数据模型设计方案影响。发散：从单体切到微服务，改的主要是”库映射元数据”这一薄层，领域代码结构不动——这正是”先领域后数据+逻辑边界一致”带来的红利。