别再让JSON字段毁了你的业务代码：从阿里商品中台案例看领域模型与数据模型的正确分工-开发者社区

领域模型与数据模型的分工艺术：从阿里商品中台实践看架构设计的本质

记得三年前接手一个电商促销系统重构时，我发现前任开发者将所有营销规则都塞进了一个名为promotion_rules的JSON字段里。当需要增加"限购地区"功能时，团队直接在JSON里追加了region_restrictions数组，而业务代码中遍布着类似JSON.parse(rule).region_restrictions.includes(userProvince)的判断——这种将数据存储结构直接暴露给业务逻辑的做法，让系统在半年内变成了无人敢动的"祖传代码"。

1. 领域模型与数据模型的本质差异

1.1 领域模型：业务语义的精确表达

领域模型是解决业务问题的概念框架，其核心价值在于显性化业务语义。在商品价格管控场景中，一个良好的领域模型应该像这样：

public class PriceRule { private List<PriceRange> ranges; private ApprovalStrategy strategy; public boolean isPriceValid(BigDecimal price) { return ranges.stream().anyMatch(range -> range.contains(price)); } } public class PriceRange { private BigDecimal min; private BigDecimal max; private RangeType type; // AUTO_APPROVE, AUTO_BLOCK等 }

这种建模方式明确表达了"价格规则由多个区间组成，每个区间有特定类型"的业务语义。当产品经理提出"某些商品需要人工复核"时，开发者可以自然地扩展ApprovalStrategy枚举，而不是在JSON里添加need_manual_review字段。

1.2 数据模型：存储效率的极致追求

数据模型的核心诉求是存储效率和访问性能。同样价格管控场景，数据库设计可能简化为：

字段名	类型	描述
id	bigint	主键
rule_name	varchar	规则名称
condition	json	价格区间配置
modified_by	varchar	最后修改人

架构师笔记：优秀的存储设计应该像乐高积木——通过有限的基础结构组合出无限可能。但业务代码不应该直接拼装这些"积木"。

2. 混淆模型的典型反模式

2.1 JSON字段滥用综合症

在商品中心系统里，我们经常见到这样的"灵活设计"：

CREATE TABLE product_extend ( product_id BIGINT PRIMARY KEY, features JSON COMMENT '商品扩展属性' );

初期看似便捷的方案，随着业务发展会出现三大致命伤：

可读性灾难：代码中充斥着feature.get("pre_sale").get("deposit_amount")这样的魔法字符串
验证缺失：无法在数据库层约束JSON结构的有效性
查询低效：即便现代数据库支持JSON查询，性能也远不及结构化字段

2.2 垂直扩展表的陷阱

阿里商品中台的auction_extend表设计确实是扩展性典范：

字段名	类型	示例值
auction_id	bigint	123456
extend_key	varchar	"presale_info"
extend_value	text	{"start":1630000}

但当业务代码直接操作这些扩展字段时，就会出现前文提到的"面向字段编程"现象。更糟糕的是，这种模式会像病毒一样扩散——当第一个团队开始用getFeature("presale_info")，其他团队会迅速效仿。

3. 模型转换的架构实践

3.1 网关模式（Gateway）的威力

COLA架构提出的Gateway模式，正是解决这类问题的银弹。以商品服务为例：

// 数据访问层 public interface ProductGateway { Product getById(Long id); } // 实现层 public class ProductGatewayImpl implements ProductGateway { public Product getById(Long id) { ProductDO productDO = dao.selectById(id); List<FeatureDO> features = featureDao.selectByProductId(id); return convertToDomain(productDO, features); } private Product convertToDomain(ProductDO productDO, List<FeatureDO> features) { Product product = new Product(); product.setId(productDO.getId()); // 将扩展字段转换为领域对象 features.forEach(f -> { if ("presale_info".equals(f.getKey())) { product.setPresaleInfo(parsePresaleInfo(f.getValue())); } // 其他字段转换... }); return product; } }

这种模式带来三个关键优势：

业务语义隔离：领域层完全感知不到底层存储结构
变更局部化：数据库结构调整只需修改Gateway实现
测试友好：可以轻松Mock网关进行单元测试

3.2 转换策略的演进

随着系统复杂度提升，我们可以引入更高级的转换策略：

策略对比表

策略类型	适用场景	实现复杂度	典型案例
硬编码转换	字段少且稳定	★☆☆☆☆	基础商品信息
注解驱动	中等规模领域模型	★★★☆☆	订单核心流程
DSL映射	高度动态的业务扩展	★★★★★	营销活动配置
元数据驱动	SaaS多租户系统	★★★★★★	电商开放平台

性能提示：对于高频访问的领域对象，可以在Gateway层引入二级缓存，缓存转换后的对象。

4. 中台架构的平衡之道

4.1 阿里商品中台的启示

深入分析阿里auction_extend的设计哲学，我们可以提炼出三个核心原则：

存储与业务解耦：扩展表只负责存储，不定义业务含义
元数据描述：通过单独的feature_meta表描述扩展字段语义
分层治理：核心字段结构化存储，长尾需求用扩展表

这种设计虽然完美解决了"不同业务线疯狂加字段"的问题，但需要配套的架构约束：

严格禁止业务代码直接查询扩展表
为每个业务线提供专用的SDK封装字段访问
建立扩展字段的注册和审计机制

4.2 现代架构的解决方案

在云原生时代，我们可以采用更优雅的解决方案：

// 使用Spring Data的Converter接口 public class ProductConverter implements Converter<ProductDO, Product> { private FeatureRepository featureRepo; public Product convert(ProductDO source) { Product product = new Product(); // 基础字段映射... // 动态扩展字段处理 featureRepo.findByProductId(source.getId()) .forEach(f -> product.addFeature( FeatureFactory.create(f.getKey(), f.getValue()) )); return product; } } // 在Repository中注册 public interface ProductRepository extends JpaRepository<ProductDO, Long> { @Override @EntityGraph(attributePaths = {"features"}) Optional<ProductDO> findById(Long id); }

配合Hibernate的@TypeDef注解，甚至可以做到JSON字段到领域对象的自动映射：

@TypeDef(name = "jsonb", typeClass = JsonBinaryType.class) public class ProductDO { @Type(type = "jsonb") @Column(columnDefinition = "jsonb") private ProductSpec spec; // 自动序列化/反序列化 }

5. 实战：重构商品评价系统

最近主导的一个电商平台重构项目，正是运用这些原则将评价系统从"字段驱动"改造为"模型驱动"的典型案例。

改造前存储设计：

CREATE TABLE item_review ( id BIGINT PRIMARY KEY, item_id BIGINT, content TEXT, features JSON -- 包含: media_urls, is_anonymous, tag_scores等 );

改造后架构：

领域模型明确定义：

public class Review { private ReviewId id; private Content content; private Media media; private AnonymousInfo anonymity; private List<TagRating> tagRatings; }

网关层转换逻辑：

public class ReviewGatewayImpl implements ReviewGateway { public Review save(Review review) { ReviewDO reviewDO = new ReviewDO(); reviewDO.setItemId(review.id().itemId()); reviewDO.setContent(review.content().text()); // 结构化字段 reviewDO.setIsAnonymous(review.anonymity().enabled()); // 动态扩展字段 reviewDO.setFeatures(JsonUtils.toJson(Map.of( "media", review.media().urls(), "tags", review.tagRatings().stream() .collect(toMap(TagRating::tag, TagRating::score)) ))); return convertToDomain(reviewDao.save(reviewDO)); } }

业务代码的蜕变：

// 改造前 if (review.getFeatures().getBoolean("is_anonymous")) { displayName = "匿名用户"; } // 改造后 if (review.anonymity().enabled()) { displayName = "匿名用户"; }

这次重构使得新需求的实施时间平均缩短40%，因为：

新增评价维度时只需扩展领域模型
业务规则检查集中在值对象方法中
存储结构调整对业务代码零影响

6. 模型转换的性能优化

当系统达到一定规模时，模型转换可能成为性能瓶颈。我们在社交平台项目中遇到过网关转换消耗15%CPU的情况，最终通过以下方案优化：

多级缓存策略：

原始数据缓存：缓存ProductDO等数据对象
领域对象缓存：缓存转换后的Product
懒加载代理：对不常用字段使用代理模式

public class ProductProxy extends Product { private Supplier<ProductDetails> detailsLoader; @Override public ProductDetails getDetails() { if (super.getDetails() == null) { super.setDetails(detailsLoader.get()); } return super.getDetails(); } }

批量转换优化：

// 低效做法 List<Product> products = productIds.stream() .map(gateway::getById) .collect(toList()); // 高效做法 List<Product> products = gateway.batchGet(productIds);

在Gateway实现内部，批量转换可以利用并行处理和缓存机制大幅提升效率。我们的压测显示，批量接口的吞吐量可达单条查询的8倍。

7. 领域模型的进化策略

优秀的领域模型不是一次性设计出来的，而是随着业务认知不断演进的。我们采用"三段式"演进策略：

初期：允许数据模型驱动领域模型，快速验证
成长期：通过DDD的限界上下文划分明确模型边界
成熟期：引入领域事件保持模型间松耦合

典型案例：商品库存模型演进

阶段	数据模型	领域模型	驱动因素
V1	单库存字段	Item.stock	简单SKU管理
V2	分仓库存表	WarehouseInventory	多仓发货
V3	库存流水表+快照	InventoryAggregate + InventoryLog	库存预占与审计
V4	分渠道库存视图	ChannelInventory	区分线上线下渠道