模块化单体应用如何划定限界上下文边界：工厂备件管理系统案例

首先明确：两个限界上下文必须保持独立 #

你完全不需要合并SpareParts和Inspections上下文，二者的领域职责边界非常清晰：

• SpareParts属于主数据域，核心职责是维护全平台备件的基础属性、分类规则、多语言映射、命名规范，所有备件主数据的变更逻辑都收敛在这个上下文
• Inspections属于业务操作域，核心职责是维护巡检流程、巡检记录、备件耗用关联关系，不需要承载任何备件主数据的管理逻辑
  合并两个上下文只会导致领域逻辑耦合，后续不管是调整备件规则还是巡检流程，都会互相干扰。

备件选择+添加到巡检对象的标准流程 #

不需要在Inspections上下文同步全量备件库的副本，你可以按以下流程实现：

1. 前端触发备件选择操作时，直接调用SpareParts上下文对外暴露的REST查询接口，SpareParts自行处理分类筛选、多语言返回、命名规则匹配等逻辑，Inspections不需要感知这部分细节
2. 用户选中目标备件后，前端将spare_part_id（SpareParts域的备件唯一标识）+ 巡检业务需要展示的核心属性（比如当前语言下的备件名称、规格型号、计量单位）同步传给Inspections服务
3. Inspections上下文在存储巡检关联备件时，只需要存以上传入的字段即可，相当于给当前巡检用到的备件存了一个业务快照

为什么要存备件快照而不是只存ID？ #

• 巡检记录属于需要留痕的历史审计数据，如果只存备件ID，后续SpareParts域的备件名称、型号等属性变更，会导致历史巡检记录里的备件信息同步变更，和实际巡检时的真实信息不符，不符合工业场景的审计合规要求
• 你只需要存当前巡检业务用到的字段即可，不需要同步全量备件属性，也不需要存储所有语言版本的属性，只需要存巡检发生时用户使用的语言对应的属性即可，存储成本极低

可选优化方案 #

如果你的场景要求SpareParts服务不可用时，巡检功能仍然可以正常选备件，可以在Inspections上下文维护一个只读的备件核心数据缓存：

• 缓存只存储备件查询需要的核心字段（ID、多语言名称、型号、状态等），不存储全量属性
• 监听SpareParts域的备件变更事件（新增/修改/停用），异步更新缓存，所有主数据的写操作仍然走SpareParts的API，保证数据唯一数据源
• 仅当SpareParts服务不可用时才降级走缓存查询，正常情况还是调用SpareParts的官方接口

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