使用 DDD 的可扩展性：使用 MEF 的 DDD 中的模块与有界上下文

Question

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

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

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

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

我们如何处理 DDD 的这种可扩展性问题？ 付款处理，一个 BC 和它下面的不同文件夹作为模块，一个用于 Paypal 等...还是我们需要在另一个 BC 中的 sub-BC？

Answer 1

Eric 在他的书中很少涉及模块的主题。他还 不讨论模块结构与 带有示例的有界上下文。

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

有界上下文是否包含模块或模块是否包含有界 上下文？

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

当应用程序具有 DDD 时，它的可扩展性有多容易？

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

Is Payment Processing，一个 BC 和它下面的不同文件夹 模块，一个用于 Paypal 等...或者我们是否需要在另一个 BC 中使用 sub-BC？

我会将每个支付处理器集成建模为单个 Payment Processing BC 中的一个模块。此外，每个集成都是您的支付处理模型与 PayPal 等第三方之间的ACL。

或者我们是否需要在另一个 BC 中使用 sub-BC？

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