DDD架构设计：图片存储用单表还是各限界上下文单独处理？

DDD 图片关联场景的架构选型方案对比 #

两种选型都符合DDD设计规范，核心取决于你的业务规模、公共需求占比和迭代规划，两者的适用边界和 trade-off 如下： #

方案1：Image作为各业务限界上下文的内置值对象 #

适用场景

• 各业务上下文对图片无通用处理需求，图片仅作为业务实体的附属属性存在，不需要统一的裁剪、水印、审核、分发等能力
• 图片整体数据量小，没有独立的存储扩容、访问加速等运维需求

优势

• 无跨服务通信开销，业务实体查询时可直接关联获取图片信息，没有额外调用成本
• 业务逻辑完全内聚，不需要维护跨上下文的映射规则，业务迭代效率更高

劣势

• 后续如果出现通用图片处理需求，会产生大量重复编码，比如多业务都需要增加涉黄涉政审核逻辑时，每个上下文都要单独对接一遍
• 存储资源无法独立调度，不同冷热属性的业务数据和图片数据混合存储，会增加后续运维成本

方案2：独立图片资源限界上下文 #

适用场景

• 多个业务上下文存在通用的图片处理需求，比如统一的格式转换、尺寸裁剪、水印添加、内容审核、CDN分发等
• 图片数据量级大，需要独立做存储扩容、访问限流、资源监控等运维操作
• 你已经明确后续要单独部署图片处理微服务，属于提前对齐架构规划

优势

• 公共能力完全复用，图片相关规则调整（比如审核标准、水印样式）仅需修改一次即可全量生效
• 存储和计算资源可独立调度，图片服务可以单独对接对象存储、CDN等资源，和业务数据库资源完全隔离，互不影响
• 符合单一职责原则，各业务上下文不需要关心图片的底层存储和处理逻辑，仅需关联图片唯一标识即可

跨服务通信复杂度优化方案

你担心的额外通信成本完全可以通过常规架构手段规避：

• 读路径做字段冗余：业务上下文可以将常用的图片访问URL作为值对象字段冗余存储，仅在图片上传、更新的写路径调用图片服务，常规读操作不需要跨服务调用
• 防腐层封装调用逻辑：用防腐层（ACL）封装图片服务的所有调用细节，业务侧仅需要调用封装好的方法，不需要感知底层通信逻辑，维护成本极低

最终决策建议 #

• 如果当前业务规模小，迭代优先级是快速上线，且没有明确的多业务通用图片处理需求，优先选择方案1。DDD本身鼓励迭代式架构演进，不需要一开始就做过度设计，后续能力需要拆分时再做演进即可
• 如果已经有多条业务线依赖图片能力，或者已经明确后续要落地独立的图片处理微服务，直接选择方案2，前期的少量接入成本会在后续迭代中被复用收益快速覆盖

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