DDD：如何在两个限界上下文处理相同业务规则及地址验证疑问

一、是否需要重复编写地址验证逻辑？ #

不用完全重复，要区分通用基础验证和上下文专属业务验证：

• 对于地址格式（如必填字段、邮编格式规范）这类不绑定业务语义的通用验证，可以抽成独立的工具类（比如AddressBasicValidator），让WorkOrder和HR两个上下文直接复用，避免重复编码。
• 但和上下文业务强绑定的验证逻辑（比如HR要求地址必须在美国），必须归属于HR上下文内部，作为HR领域的核心业务规则，不能和WorkOrder的逻辑混在一起。WorkOrder上下文不需要关心这个约束，因为它的业务场景不要求地址在美国。

二、如何避免WorkOrder的写入操作违反HR的约束？ #

结合你们共享数据库的模块化单体架构，推荐以下几种方案：

• 明确数据所有权与访问边界：把带美国地址约束的Person数据的所有权划归HR上下文，WorkOrder上下文只能通过HR提供的领域服务或内部API来修改地址数据，不能直接操作数据库表。所有修改请求都会经过HR上下文的验证逻辑，从根源上避免违反约束。
• 数据库层补充防护（可选）：如果担心代码层的隔离出现漏洞，可以在HR对应的Person表地址字段上添加数据库检查约束（比如限制国家字段值为US）。但这种方式仅作为兜底，不要把核心业务规则完全依赖数据库约束实现，否则会导致业务逻辑分散，难以维护。
• 本地事件触发验证：在单体架构内，可以通过本地事件机制，当WorkOrder上下文尝试修改地址时，触发HR上下文的验证事件，由HR侧校验是否符合自身约束，不符合则直接终止修改操作并返回错误。
• 数据冗余与单向同步：如果两个上下文的Person是数据库中的不同表，WorkOrder可以维护自己无地址约束的Person副本，HR的Person表作为权威数据源。仅当HR侧的地址修改时，同步更新WorkOrder的副本；WorkOrder侧不能反向修改HR的权威数据，从数据流向层面避免冲突。

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