领域驱动实战-支付系统
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了领域驱动实战-支付系统相关的知识，希望对你有一定的参考价值。
参考技术A 在Airwallex，领域驱动设计(DDD)方法被用来指导我们的工程师如何对复杂的业务问题和系统设计建模。在这篇博客中，我们提供了一个全面的工作流，我们使用DDD模式进行建模，然后对支付系统进行落地。全球支付系统是复杂和不断变化的，涉及从订单、欺诈、通知、与各种支付方式的集成到清算和结算等广泛的板块。
在处理复杂的系统时，大多数开发人员可能会遇到一些一致的问题：
在Airwallex，领域驱动设计(DDD)方法被用来指导我们的工程师如何解决复杂的业务问题和系统建模。
然而，DDD只是各种模式的集合，很难将其应用于系统设计。在这篇博客中，我们提供了一个全面的工作流程，介绍了我们是如何在Airwallex应用领域驱动设计的，从中得到的经验教训，以及我们接下来要做什么。
领域驱动设计(由Eric Evans提出)是一组帮助基于业务领域的底层模型设计软件系统的思想、原则和模式。DDD有两个不同的空间，问题空间和解决方案空间。
在问题空间中，您使用战略模式定义系统的顶层的系统层次，这些战略模式关注域、子域和通用语言的分析。
在解决方案空间中，采用战术模式来提供一组设计模式，您可以使用这些设计模式创建领域模型。这些模式包括有界上下文、上下文映射、实体、聚合、领域事件、领域服务、应用程序服务和基础设施。这些战术模式将帮助您设计既松散耦合又具有内聚性的微服务。
下面是一个常见的案例:
一位顾客想在该商家的网站上购买一件价格为10美元的t恤。顾客可以用多种支付方式来支付这件t恤，比如Visa卡或微信钱包。在客户支付后，商家会从支付网关收到一个通知，显示客户的支付已经成功。然后，商家可以在Airwallex webapp中查看支付细节，包括购买价格、商家费用以及资金将何时进入Airwallex Global Account钱包。
下面是分析结果。
支付系统
付款处理：商家可以通过各种付款方式接受客户的付款。
金融：清算和解决商家的付款资金。
付款意向：商家创建的订单的价格，产品，客户等。
付款尝试：商家创建的交易以获得订单的客户。
付款方式：客户支付产品的方式。
付款结算：付款之 后钱进入商家钱包。
付款视图：汇总付款详细信息视图，包含与一笔付款相关的所有数据。
有界上下文(BC)限定了域模型的范围。根据对问题空间的分析结果，我们可以定义以下边界上下文：
支付网关: API网关，为商家提供restful API来创建或查看支付。
支付核心模块: 支付意图，方法资源管理。
支付适配器: 与一个外部的PSP集成，例如微信，支付宝，Visa，万事达等。
支付结算: 计算并结算商户每次支付的原则和费用。支付融合:支付明细汇总视图。
下面是生成的上下文映射的一个示例：
从上面分析的场景和通用语言中，我们可以确定以下聚合、实体、值对象和域事件：
根据我们的经验，领域服务为单个聚合使用业务逻辑服务，遵循单一责任。通常，我们将封装领域仓储、聚合修改和在领域服务中发布的领域事件。以PaymentAttemptExecutorService为例：
领域事件可以使系统更具有可扩展性，并避免任何耦合，且一个聚合不应该决定其他聚合应该做什么。
例如，当PaymentCaptureCommand命令将支付状态更改为已支付时，会发出领域事件PaymentAttemptCapturedEvent。在PaymentAttemptCapturedEvent的领域事件处理程序（EventHandler）中，我们可以在该业务逻辑上加上你想要的逻辑。例如，通知支付聚合有界上下文更新支付详情，通知支付结算有界上下文计算结算金额和费用。
在DDD模式中，基础设施层作用于将核心业务领域与技术实现细节分开。该层通常采用ACL (anti - corruption-layer)模式。以领域仓储为例：
领域仓储只定义接口功能，但实现细节应该隐藏在基础设施层中，细节上你可以使用PostgreSQL或MongoDB来保存数据。例如，在基础设施层中，PaymentAttemptPgRepository是基于PostgreSQL的特定实现，而toPO是一个转换器，用于将域对象PaymentAttempt转换为持久化对象。
现在，我们已经为支付系统定义了一组有界上下文，并在每个有界上下文中标识了一组实体、聚合和领域事件服务。下一步是从域模型到应用程序微服务设计。这里，我们选择将一个有边界的上下文映射到一个微服务。
采用DDD可以提供许多好处，例如，在所有团队之间进行清晰的沟通，以及在设计系统时使用成熟的模式来管理复杂性并提供更好的可伸缩性。
使用通用语言，我们可以实现更多的自描述类名和函数名。
使用聚合模式，我们可以实现清晰的边界和单一的职责。
使用领域事件模式，我们可以分割核心业务流程，减少聚合之间的耦合。
通过基础设施层和ACL模式，我们可以将核心业务领域模型与技术实现细节分离开来。通过限定上下文模式，我们可以派生出潜在的微服务候选对象。
在实践中应用DDD时，我们想要分享一些挑战和经验教训：
原文地址： https://medium.com/@chaojie.xiao/domain-driven-design-practice-modeling-payments-system-f7bc5cf64bb3
2019领域驱动设计峰会领域场景驱动设计实战工作坊
领域场景驱动设计实战工作坊
-
专注于行业软件开发或互联网开发的软件从业者 -
希望掌握事件风暴方法的业务分析人员与开发人员 -
希望提高领域建模与分析能力的软件设计人员 -
希望掌握领域驱动设计方法并运用到项目中的后端开发人员
领域驱动设计过程
探索业务全景
通过识别事件风暴的领域事件，并利用事件因果关系的驱动力识别各自的前置事件和后置事件，形成一条或多条代表了时间轴的事件流。探索过程包括：
识别代表业务全景的领域事件
标记代表问题、重要关注点的热点
为每个领域事件识别参与者
领域分析建模
根据领域事件确定决策命令
根据决策命令确定读模型
根据决策命令和领域事件之间的关系确定聚合
根据读模型、聚合获得领域分析模型
场景驱动设计
场景驱动设计的过程
-
识别场景： 从需求中识别出独立的具有业务价值的领域场景 -
分解任务： 根据职责的层次对领域场景进行任务分解 -
分配职责： 为领域驱动设计角色构造型分配不同层次的职责
测试驱动开发
场景驱动设计与测试驱动开发之间形成了一种相辅相成的设计伴侣。场景驱动设计分解出来的任务以及角色构造型的协作时序图，可以作为测试驱动开发的起点。测试驱动开发的代码编写又反过来验证场景驱动设计的正确性，并通过重构改进代码质量，并重新发现之前未曾发现的隐含概念。在本次工作坊中，我们将选择一个领域场景，严格按照测试驱动开发的开发节奏进行。
以上是关于领域驱动实战-支付系统的主要内容，如果未能解决你的问题，请参考以下文章