在 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 模式中的每一个主题，如层治理、畛域事件存储、上下文映射模式等。