28

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

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

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

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

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

4

1 回答 1

30

Eric 在他的书中很少涉及模块的主题。他也没有通过示例讨论模块结构与有界上下文的关系。

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

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

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

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

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

付款处理，一个 BC 和它下面的不同文件夹作为模块，一个用于 Paypal 等......还是我们需要另一个 BC 中的子 BC？

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

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

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

于 2012-12-24T17:12:22.313 回答