Eric在他的书中很少涉及模块的主题。他也没有谈到模块结构与有界上下文的关系和例子。有界上下文是否包含包含有界上下文的模块或模块？当一个应用程序有DDD时，它是多么容易扩展？
当我们设计可扩展应用程序时，应用程序的结构非常重要。 Microsoft MEF框架可以从dll自动发现模块/组件。
让我们举个例子。在电子商务应用程序中，我们可以为付款处理提供有限的上下文。付款处理可以是抽象的，因此我可以稍后使用Paypal或Payflow等更多支付处理器扩展应用程序。目前我只有Paypal，几个月后我想整合Payflow。为了集成Payflow，我可以有一个程序集（一个dll）来实现支付处理的界面。我可以在应用程序中删除该dll，MEF将自动发现它。
这里的挑战是，为PayFlow支付处理创建的DLL是一个模块，而不是有界上下文（BC）。如果我将其创建为BC，我们有两个用于付款处理的BC。 （BC为Paypal创建，BC为Payflow创建）。如果我们使用Bounded Context中的模块和Bounded Context作为程序集（dll）构建应用程序，那么模块可以作为文件夹而不是程序集驻留在BC中（您可以将其视为在Visual Studio中创建的C＃库）。
我们如何使用DDD处理这种可扩展性问题？是付款处理，BC和它下面的不同文件夹作为模块，一个用于Paypal等...或者我们是否需要在另一个BC内的子BC？
答案 0 :(得分：21)
埃里克在他的书中很少涉及模块的主题。他还 没有谈到模块结构的关系 有限的上下文与例子。
是的，我同意模块和BC结构在本书中没有得到足够的覆盖。我建议Implementing Domain-Driven Design by Vaughn Vernon了解更多信息。
Do Bounded Contexts包含模块或模块包含Bounded 上下文
BCs包含模块。模块就像一个轻量级的BC，也属于无处不在的语言。
当应用程序有DDD时，它可以扩展多么容易？
这取决于你如何设计它。 DDD本身没有什么可以阻止可扩展性。
付款处理，BC和其下的不同文件夹 模块，一个用于Paypal等...或者我们是否需要另一个BC内的sub-BC？
我会将每个支付处理器集成模型化为单个支付处理BC中的模块。此外，您的付款处理模式与第三方（如PayPal）之间的每次整合均为ACL。
或者我们是否需要另一个BC内的sub-BC？
不，但这触及了一个有趣的概念，即子BC。我认为sub-BC不是一个好主意，因为我认为分层组织可能是危险的，导致严格的设计（例如，查看具有显式类型层次结构的OOP）可能会有问题。相反，选择具有更多BC的更平坦的模型。此外，在您的情况下，可以使用模块实现所需的结构。