DDD落地：限界上下文划分与退款场景建模问题咨询

不应当，干系人维度从来都不是限界上下文划分的核心依据。
限界上下文的核心边界判定标准是领域语义一致性：同一个业务概念、业务规则在边界内必须有唯一、无歧义的定义，边界拆分的本质是对业务领域本身的分类，而非对系统使用者的分类。你们团队当前的划分逻辑存在本质误区：把「操作触发方」等同于「业务能力归属方」——干系人只是动作的发起入口，不是业务规则的宿主。举个最简单的例子：不管是用户自己点注册，还是管理员帮用户代注册，「账号合法性校验、账号创建」的核心规则都属于账号域，不会因为操作人变了就变成两套独立规则。

不能一概而论，但你们当前遇到的核心业务规则重复，是典型的边界划分错误的坏味道。
你需要先区分两种完全不同的重复：

• 语义无关的偶然重复：比如客户域的「手机号格式校验」和卖家域的「手机号格式校验」，看似逻辑一样，但两个域的校验规则未来可能独立演化（比如卖家要求必须绑定企业手机号、客户允许个人手机号），这种重复是合理的，强行抽成公共组件反而会造成不必要的耦合。
• 语义完全一致的重复：比如退款场景下「退款金额不能超过订单实付金额、退款成功后要触发资金退回、退款状态要和订单状态联动」这类规则，不管谁发起退款，业务语义没有任何区别，这种重复就是实打实的设计问题。后续只要规则调整，你就要同步改多个上下文的代码，漏改就会出逻辑不一致的故障，维护成本会随着迭代快速升高。

你们当前是单体应用，没有跨服务通信的额外成本，调整成本很低，核心原则是把「核心业务能力」和「操作入口/权限逻辑」解耦，具体可以按下面的方式落地：

• 第一步：先把散落在各个干系人上下文里的交易类核心逻辑抽离，单独划分交易结算上下文。所有和退款相关的核心领域模型（退款单实体、退款状态流转规则、退款金额校验、退款触发的资金/库存/优惠券回滚逻辑）全部收敛到这个上下文，作为全系统唯一的退款规则实现方。
• 第二步：原有的Seller、Admin这类按干系人划分的模块，退化为面向不同角色的接入层，不再持有核心业务规则：
  • Seller侧的退款逻辑只做三件事：校验当前操作人是对应订单的归属卖家、校验卖家提交的退款参数格式、记录卖家操作日志，之后直接调用交易结算上下文的统一退款接口
  • Admin侧的退款逻辑同理：校验当前操作人有代操作退款的权限、校验代退关联的卖家/订单真实存在、记录管理员操作留痕，之后调用同一个交易结算的退款接口
• 第三步：如果不同角色发起退款存在流程差异（比如卖家自主退1000元以下不需要审核，管理员代退无论金额多少都需要二次审核），不要拆分核心退款规则，通过策略模式在交易结算上下文内做分支扩展，或者在上层做轻量流程编排即可，核心的退款原子逻辑始终保持单一实现。

单体场景落地DDD不用追求过度拆分，限界上下文首先是代码模块的职责边界、是团队开发的权责边界，不用急着拆成独立服务，先把语义边界划清楚，就能解决你现在遇到的大部分重复代码问题。

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