DDD架构下依赖根聚合的1:N值对象持久化方案咨询

首先把大前提说在前头：DDD中持久化是纯基础设施层的职责，绝对不能让数据库设计规则反过来入侵领域层建模，值对象就是值对象，不会因为你用了MySQL就必须变成实体，这是所有决策的底线。

针对你提的三个具体问题，直接给可落地的判断逻辑：

• 关于“MySQL下是否必须给1:N集合类值对象单独建表”
  没有非黑即白的强制要求，完全看场景选。
  如果你遇到的情况和你举的咖啡馆场景一致：单个聚合下的值对象条目量很少（常规营业时间最多7条，临时开闭店一般也就几十条顶天），没有跨聚合直接查询/统计这些值对象条目的需求，90%的场景都是加载聚合根的时候顺带把所有值对象一起取出来，那直接在聚合根主表加opening_hours JSON类型字段，把整个值对象序列化存进去是最优解。这种方式没有多表join开销，加载/保存聚合一次单表操作就能完成，值对象和聚合根生命周期完全绑定，删聚合的时候不用额外处理关联表垃圾数据，开发成本极低。
  要是你遇到的场景是单聚合下值对象条目量极大（比如存未来一整年每半小时的营业配置，单咖啡馆下有上万条时间条目），或者有大量跨聚合针对时间条目的查询统计需求，存JSON会导致主表记录过大拖垮查询性能，那就拆关联表。注意拆表的时候不需要给这些时间条目加任何业务意义上的标识，只需要加数据库层面的自增主键当物理ID，外键关联咖啡馆的全局guid就行，且所有对这些时间条目的增删改查必须通过Cafe聚合根完成，绝对不允许绕过聚合根直接操作关联表数据。

• 关于“RDBMS是否必须做范式化设计，不然不如用NoSQL”
  这个说法完全是把手段当目的。数据库范式化的核心价值是减少数据冗余、避免更新异常，要是你的场景里根本拿不到这个收益，硬套范式只会增加无意义的复杂度。
  你这里的营业时间是完全依附于Cafe聚合的值对象，根本不存在“同一条营业时间配置被多个咖啡馆复用”的场景，改某个咖啡馆的营业时间本来就只会修改这个咖啡馆自己的数据，完全不会出现数据不一致、更新异常的问题，范式化拆表的收益几乎为0，反而要多写好几层关联查询、多处理几个表的事务，纯纯给自己加活。
  再者MySQL从5.7版本开始就原生支持JSON类型、JSON路径索引，用合适的字段类型存储对应结构的数据本来就是正确用法，不存在“用了JSON就不算用关系型数据库”的荒谬说法。

• 关于“查询半径10公里内当前营业的咖啡馆”的需求实现
  不管你选存JSON还是拆表，都能实现，优先选性能最高、开发成本最低的方案就行：

  • 坐标半径过滤：直接用MySQL原生空间索引，给坐标字段建POINT类型的空间字段，基于ST_Distance_Sphere函数做半径计算，这是非常成熟的方案，性能足够支撑常规业务量，别自己手写经纬度距离计算公式。
  • 营业状态过滤：别硬写SQL实时遍历营业时间条目算状态，高并发下性能极差。不管你选哪种存储结构，都可以在Cafe主表加几个预计算的冗余字段，比如is_open_now、next_close_time，每次新增、修改营业时间配置的时候，通过领域层逻辑提前算好这些字段的值存在主表，查询的时候直接加is_open_now = 1的过滤条件就行，性能拉满。要是你后续有更复杂的营业时间查询需求，再考虑调整存储结构也完全来得及。

最后补个核心判断标准：只要你能保证所有存储逻辑都封装在仓储实现里，领域层的聚合、值对象结构完全感知不到底层是存JSON、拆了表、还是换了MongoDB，那你的设计就是符合DDD要求的，根本不存在“正确的唯一表结构”这种说法。
针对你当前的咖啡馆业务场景，直接存JSON+空间索引+主表冗余营业状态字段是性价比最高的选择，没必要硬拆关联表。

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