领域驱动设计实践：支付系统建模

在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。

在这篇博客中，我们试图全面介绍用DDD模式对支付系统进行建模的做法。

简介

支付系统是一个相当复杂和多变的系统，从订单、欺诈、通知、与各种支付方式的整合到资金清算和结算，涉及面很广。

在处理一个复杂的系统时，大多数开发人员可能会遇到一些问题

• 边界和责任不明确，只是一个有许多模型和业务逻辑的大应用程序。
• 没有隔离和模块化：复杂的业务工作流和流程是混合的，难以扩展。
• 没有关注点的分离：核心业务逻辑与技术实现细节混在一起。

软件行业中的许多设计模式都能解决这些问题，在Airwallex，我们尝试采用领域驱动设计（DDD）的方法来为我们的支付系统建模，以管理系统设计中的复杂性。

什么是DDD

领域驱动设计（DDD）是由埃里克-埃文斯（Eric Evans）提出的，它是一套思想、原则和模式，有助于根据业务领域的基础模型设计软件系统。DDD有两个不同的空间：问题空间和解决方案空间。

在问题空间，你是用战略模式来定义系统的大规模结构，它专注于分析一个领域、子领域和泛在语言。

而在解决方案空间中，采用战术模式来提供一套设计模式，你可以用它来创建领域模型。这些模式包括有界的上下文、上下文映射、实体、聚合体、领域事件、领域服务、应用服务和基础设施。这些战术模式将帮助你设计既松散耦合又有凝聚力的微服务。

如何在实践中应用DDD

想象一下，有这样一个场景：

• 一位顾客想在商家的网站上购买一件T恤，价格是10美元。
• 顾客可以用各种支付方式来支付这件T恤，如Visa卡或微信钱包。
• 客户付款后，商家可以从支付网关获得通知，这样他们就可以向客户展示付款成功的页面。
• 商户可以在Airwallex Webapp中查看付款详情，这样他们就可以知道这件T恤可以获得多少资金，Airwallex扣除了多少费用，以及资金何时会被结算到他的Airwallex钱包。

将遵循以下步骤，应用DDD对基于上述场景的支付系统进行建模。

• 分析现实世界中的业务用例，以获得问题空间中的域和子域。通常，在这个阶段，Event Storming是一个很好的工具。
• 定义解决方案空间中的有界上下文
• 在有界限的上下文中，应用战术性DDD模式来定义实体、聚合、领域服务、领域事件等。
• 使用上一步的结果来确定你的团队中的微服务。

以下是分析结果。

问题空间

• 领域

支付系统

• 子域

- 支付处理：商家可以通过各种支付方式接受客户的付款- **金融：对商家的支付资金进行清算和结算。

• 通用语言

在与领域专家讨论后，以下是所有团队接受的通用语言。

- 支付意图：商家创建的订单，指定价格、产品、客户等。

- 付款企图：商家创建的交易，以接受客户对特定订单的付款。

- 付款方式：客户为产品或服务付款的方式。

- 付款结算：一批结算到商家钱包的付款。

- 付款视图：一个聚合的付款细节视图，包含与一个付款有关的所有数据。

解决方案空间

• 有界上下文

有界上下文（BC）限定了一个领域模型的范围。从问题空间的分析结果来看，我们可以定义以下有界上下文。

- 支付网关：API网关，为商户提供可靠的API，以创建或查看付款。

- 支付核心：支付意图、尝试、方法资源管理。

- 支付适配器：与一个外部PSP（微信/支付宝/Visa/Mastercard等）集成。

- 支付结算：为商户计算和结算每笔支付的原则和费用。

- 支付融合：支付细节的聚合视图。

而上下文地图将是这样的：

• 领域模型

从上面我们分析的场景和无所不在的语言中，我们可以确定以下聚合、实体、价值对象和领域事件。

• 领域服务

在我们的实践中，域服务是为一个聚合体提供的无状态业务逻辑服务，遵循单一责任模式。通常情况下，我们会在领域服务中封装领域仓库、聚合变化和领域事件发布。以PaymentAttemptExecutorService为例。

• 领域事件

领域事件可以使系统更具可扩展性，并避免任何耦合--一个聚合体不应该决定其他聚合体应该做什么，以及时间耦合--付款的成功完成并不取决于所有进程在同一时间可用。

例如，当PaymentCaptureCommand将支付状态改为已支付时，领域事件PaymentAttemptCapturedEvent被发送，以通知聚合的PaymentAttempt被捕获。在PaymentAttemptCapturedEvent的领域事件处理程序中，我们可以把副作用放在业务逻辑上，比如通知支付融合的边界上下文来更新支付细节和支付结算的边界上下文来计算结算金额和费用。

• 基础设施

在DDD模式中，基础设施层被用来将核心业务领域与技术实现细节分开。通常，该层采用反污层（ACL）模式。以领域存储库为例。

领域仓库只定义了接口，比如他们能做什么，但实现细节应该隐藏在基础设施层里面，比如使用PostgreSQL或MongoDB来保存数据。例如，在基础设施层，PaymentAttemptPgRepository是基于PostgreSQL的具体实现，toPO是用于将域对象PaymentAttempt转换为持久化对象的映射器。

因此，在领域层，我们只关注领域模型，它与基础设施技术完全脱钩。当基础设施层有任何变化时，不需要在领域层中进行改变。

从领域模型到微服务

现在，我们已经为支付系统定义了一组有边界的上下文，并在每个有边界的上下文中确定了一组实体、集合体和领域事件服务。

下一步就是要从领域模型到应用微服务的设计。

在这里，我们选择将一个有界上下文映射到一个微服务。

结论

在这篇博客中，当我们试图对支付系统进行建模时，我们触及了领域驱动设计（DDD）模式的各种概念和策略。采用DDD可以提供许多好处，例如，在所有的团队中进行清晰的沟通，以及在设计系统时提供一个成熟的模式来管理复杂性和提供更好的可扩展性。

• 有了无处不在的语言，我们可以实现更多的自我描述的类名和函数名。
• 通过聚合模式，我们可以实现清晰的边界和单一的责任。
• 通过领域事件模式，我们可以将核心业务流程与聚合体上的副作用分开。
• 通过基础设施层和ACL模式，我们可以将核心业务领域模型与技术实现细节分开。
•  通过有边界的上下文模式，我们可以推导出潜在的微服务候选人。

DDD模式是一个庞大的话题，我认为我们做得还不够充分，无法全面解释它们，但我们想介绍一些关键的话题和我们实践该模式的经验。在未来，我们将继续深入研究DDD模式中的每一个主题，如层管理、领域事件存储、上下文映射模式等。