基于DDD建模含外部支付系统的订阅管理场景的技术疑问

背景 #

近几周一直在学习Domain Driven Design（DDD），阅读相关文章与书籍，但当前公司并未采用DDD原则做软件设计。所以常思考如何用DDD建模业务问题，虽理解不少DDD概念，但仍有部分没完全吃透。

现以一个具体案例请教：
待设计的系统需管理带有定期支付（recurring payment）的订阅（subscriptions），类似Netflix流媒体订阅。系统依赖一个外部支付系统，该系统仅提供REST API，无消息发布/订阅（Pub/Sub）基础设施。

目前的思路是：订阅领域模型中维护一个记账（bookings）列表，每个记账项包含外部支付系统的ID，用于跟踪订阅的所有支付记录。

问题1：该领域模型是否存在更优的实现方案？ #

问题2：添加支付记录的两种工作流，哪种更适合DDD建模？或是该场景不适用DDD？ #

两种工作流：

1. 先调用外部支付系统获取支付ID，再创建记账领域模型并添加至订阅中；
2. 先创建记账模型并触发领域事件，由事件处理程序调用外部支付系统创建支付，再更新记账模型中的支付ID。

问题1解答 #

当前思路可行，但可从领域表达精准性、聚合边界角度做优化：

• 拆分支付相关概念：将「记账」拆分为领域内的PaymentAttempt（支付意图）和与外部绑定的PaymentConfirmation（支付确认记录）。这样能区分“发起支付请求”与“支付完成确认”两个不同业务状态，避免把外部系统的强依赖直接耦合到核心订阅模型。
• 用聚合根行为管控状态：不给Subscription直接暴露记账列表的修改权限，而是添加initiateRecurringPayment()、confirmPaymentSuccess()等方法，由这些方法封装业务规则（比如同一周期禁止重复发起支付），内部处理支付记录的添加与状态变更，保证领域规则的一致性。
• 拆分聚合边界（可选）：如果支付记录的查询、统计需求复杂，可将支付记录抽为独立聚合，订阅仅保留与支付记录的关联ID，避免订阅聚合因支付记录过多而膨胀，影响模型纯粹性与性能。

问题2解答 #

两种工作流都适配DDD，需结合外部系统特性与业务风险选择：

选择工作流1的场景

若外部支付系统可用性极高，且业务要求“仅支付成功后，才能在订阅中留存有效记录”，工作流1更直接：

• 把调用外部支付系统的逻辑放在应用层，领域模型只负责接收支付ID并创建合规的记账项，避免外部依赖污染核心领域。
• 需处理调用失败场景：比如超时或支付失败时，应用层要做重试、补偿，或给订阅标记“支付发起失败”状态，防止数据不一致。

选择工作流2的场景

若外部支付系统稳定性一般，或业务允许“先记录支付意图，再异步完成支付”，工作流2更贴合DDD的领域驱动思想：

• 先在领域内创建PaymentAttempt并触发PaymentInitiated领域事件，这一步完全是领域内操作，不依赖外部系统，保证了领域模型的独立性。
• 应用层的事件处理器负责调用外部支付系统，成功后触发PaymentConfirmed事件，由订阅聚合根更新支付状态、绑定外部支付ID。
• 因无Pub/Sub，事件处理可采用同步回调或定时轮询：比如处理器调用外部API后同步更新记账项，或记录任务到定时队列，轮询支付结果。这种方式的优势是解耦外部依赖与领域核心，即使外部系统故障，领域内的支付意图依然可追溯，后续可重试。

场景适配性说明

该场景完全适合DDD：订阅是典型的核心业务领域，存在明确的业务规则（如订阅周期约束、支付失败后的暂停/续费规则、取消订阅的限制），用DDD可将这些规则封装在聚合根内，避免业务逻辑散落在各层。只要不把外部系统细节硬塞进领域模型，保持领域纯粹性即可。

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