domain-driven-design - DDD : Module Vs Bounded Context in DDD with MEF 可扩展性

Question

Eric 在他的书中触及了 的主题。模块 很少。他也没有通过示例讨论模块结构与有界上下文的关系。限界上下文是否包含模块或模块包含限界上下文？当应用程序具有 DDD 时，它的可扩展性有多容易？

在我们设计可扩展应用程序时，应用程序的结构非常重要。 Microsoft MEF 框架可以从 dll 中自动发现模块/组件。

让我们举个例子。在电子商务应用程序中，我们可以为 提供有界上下文。付款处理 .支付处理可以是抽象的，因此我可以稍后使用更多支付处理器(如 Paypal 或 Payflow)扩展应用程序。目前我只有Paypal，几个月后我想整合Payflow。为了集成 Payflow，我可以有一个实现 接口(interface)的程序集(一个 dll)。付款处理 .我可以将该 dll 放到应用程序中，MEF 会自动发现它。

这里的挑战是，为 PayFlow 支付处理创建的 dll 是一个模块，而不是有界上下文 (BC)。如果我将其创建为 BC，我们有两个 BC 用于 付款处理 . (为 Paypal 创建的 BC 和为 Payflow 创建的 BC)。如果我们使用限界上下文中的模块和限界上下文作为程序集 (dll) 构建应用程序，则模块可以作为文件夹而不是程序集驻留在 BC 中(您可以将其视为在 Visual Studio 中创建的 C# 库)。

我们如何使用 DDD 处理这个可扩展性问题？是 付款处理 ，一个 BC 和它下面的不同文件夹作为模块，一个用于 Paypal 等......或者我们是否需要另一个 BC 内的子 BC？

Answer 1

Eric in his book touches the subject of Modules very little. He also does not talk about the relation of the structure of modules to bounded contexts with examples.

是的，我同意模块和 BC 结构在书中没有得到足够的覆盖。我推荐 Implementing Domain-Driven Design by Vaughn Vernon了解更多信息。

Do Bounded Contexts contain modules or modules contain the Bounded Contexts?

BC 包含模块。模块就像一个轻量级的 BC，也属于泛在语言。

When an application has DDD, how easy it can be extendable?

这取决于你如何构建它。 DDD 本身不会妨碍可扩展性。

Is Payment Processing, a BC and different folders beneath it as modules, one for Paypal etc... Or do we need sub-BC inside another BC?

我会将每个支付处理器集成建模为单个支付处理 BC 中的一个模块。此外，每个集成都是一个 ACL在您的付款处理模型和第三方(例如 PayPal)之间。

Or do we need sub-BC inside another BC?

不，但这涉及到一个有趣的 sub-BC 概念。我不认为 sub-BC 是一个好主意，因为我相信分层组织可能会导致僵化的设计(例如，查看具有显式类型层次结构的 OOP - 可能会出现问题)。相反，选择具有更多 BC 的更扁平模型。此外，在您的情况下，可以使用模块来实现所需的结构。