Domain driven design DDD的可扩展性：模块与MEF DDD中的有界上下文

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

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

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

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

我们如何用DDD处理这个扩展性问题？是支付处理，一个BC和它下面的不同文件夹作为模块，一个用于贝宝等。。。还是我们需要在另一个BC中使用子BC

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

是的，我同意模块和BC结构在本书中没有得到足够的介绍。我建议更多关于这方面的信息

有界上下文包含模块还是模块包含有界上下文 上下文

BCs包含模块。模块类似于轻量级BCs，也属于泛在语言

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

这取决于您如何构建它。DDD本身的任何内容都不会阻止可扩展性

是支付处理，一个BC和它下面的不同文件夹作为 模块，贝宝等一个。。。还是我们需要在另一个BC中使用子BC

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

还是我们需要在另一个BC中使用子BC

---

不，但这涉及到一个有趣的亚BC概念。我认为子BC不是一个好主意，因为我认为层次结构组织可能会导致僵化的设计（例如，看看带有显式类型层次结构的OOP——可能会有问题）。取而代之的是，选择一种可能有更多BCs的更平坦的车型。此外，在您的情况下，可以通过模块实现所需的结构。

Great answer@eulerfx！