问题描述
他的书中的埃里克（Eric）很少触及模块的主题。他还没有通过示例讨论模块结构与有限上下文的关系。绑定上下文包含模块还是模块包含绑定上下文？当应用程序具有DDD时，可扩展性有多容易？
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. Do Bounded Contexts contain modules or modules contain the Bounded Contexts? When an application has DDD, how easy it can be extendable?
在设计可扩展应用程序时，应用程序的结构非常重要。 Microsoft MEF框架可以从dll中自动发现模块/组件。
The structure of the application is very important when we design Extensible applications. The Microsoft MEF framework can auto-discover modules/components from a dll.
让我们举个例子。在电子商务应用程序中，我们可以具有付款处理的受限上下文。付款处理可以是抽象的，因此我以后可以使用更多付款处理器（如Paypal或Payflow）扩展该应用程序。目前，我只有Paypal，几个月后，我想集成Payflow。为了集成Payflow，我可以使用一个程序集（dll）来实现 Payment Processing 的界面。我可以将该dll放入应用程序中，MEF会自动发现它。
Let us take an example. In an e-commerce application, we can have a bounded context for Payment Processing. The Payment Processing can be abstract, so I can later extend the app with more Payment Processors like Paypal or Payflow. Currently I have only Paypal, and few months later I want to integrate Payflow. To integrate Payflow, I can have a assembly (a dll) that implements the interface of the Payment Processing. I can drop that dll in the application, and the MEF will auto discover it.
这里的挑战是，为PayFlow付款处理创建的dll是一个模块，而不是边界上下文（BC）。如果我将其创建为BC，则我们有两个用于付款处理的BC。 （BC为Paypal创建，BC为Payflow创建）。如果我们使用绑定上下文中的模块和作为绑定（dll）的绑定上下文来构建应用程序，则这些模块可以作为文件夹而不是组件驻留在BC中（您可以将其视为在Visual Studio中创建的C＃库）。
The challenge here is, the dll created for the PayFlow payment processing is a module, not a Bounded Context (BC). If I created it as a BC, we have two BCs for Payment Processing. (The BC created for Paypal and the BC for the Payflow). If we structure the application with modules inside a Bounded Context and the Bounded Context as a assembly (dll), the modules can reside in the BC as folders and not assemblies (you can think of it as a C# library created in Visual Studio).
我们如何处理DDD的可扩展性问题？是 Payment Processing ，一个BC和位于其下的不同文件夹作为模块，一个用于Paypal的文件夹等...还是我们需要在另一个BC中的sub-BC？
How can we handle this extensibility problem with 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结构在本书中没有充分介绍。我建议，以了解更多信息。
Yes, I agree that module and BC structure don't get sufficient coverage in the book. I recommend Implementing Domain-Driven Design by Vaughn Vernon for more on this.
BC包含模块。模块就像轻量级的BC一样，也属于普遍存在的语言。
BCs contain modules. A module is like a lightweight BCs and also belongs in the ubiquitous language.
这取决于您如何设计它。 DDD本身并不能阻止可扩展性。
That depends on how you architect it. Nothing about DDD itself would prevent extensibility.
我会将每个付款处理器集成建模为其中的一个模块单个付款处理BC。此外，每个集成都是您之间的
I would model each payment processor integration as a module within a single Payment Processing BC. Additionally, each integration is an ACL between your payment processing model and a 3rd party such as PayPal.
不，但这涉及到一个有趣的sub-BC概念。我认为sub-BC并不是一个好主意，因为我认为层次结构组织可能会导致僵化的设计（例如，使用显式类型层次结构查看OOP可能会出现问题）。相反，选择具有更多BC的更平坦的模型。另外，根据您的情况，可以使用模块实现所需的结构。
No, but this touches on an interesting notion of a sub-BC. I don't think a sub-BC is a good idea because I believe hierarchical organizations can be dangerous leading to rigid designs (look at OOP with explicit type hierarchies for instance - can be problematic). Instead, opt for a flatter model with potentially more BCs. Also, in your case, the desired structuring can be achieved with modules.
这篇关于具有DDD的可扩展性：具有MEF的DDD中的模块与有界上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！