当我们设计可扩展应用程序时,应用程序的结构非常重要. Microsoft MEF框架可以从dll自动发现模块/组件.
让我们举个例子.在电子商务应用中,我们可以为付款处理提供有限的上下文.付款处理可以是抽象的,所以我可以稍后使用更多付款处理器(如PayPal或Payflow)来扩展应用程序.目前我只有PayPal,几个月后我想集成Payflow.要集成Payflow,我可以有一个程序集(一个dll)来实现付款处理的接口.我可以把这个dll放在应用程序中,MEF会自动发现它.
这里面临的挑战是,为PayFlow支付处理创建的dll是一个模块,而不是一个有界的上下文(BC).如果我创建它作为BC,我们有两个BC支付处理. (BC为BCB创建,BC为Payflow).如果我们使用有限的上下文中的模块和有限的上下文作为程序集(dll)来构造应用程序,那么这些模块可以作为文件夹而不是程序集驻留在BC中(您可以将其视为在Visual Studio中创建的C#库).
我们如何处理DDD的这个可扩展性问题？是付款处理,BC和不同的文件夹在它下面作为模块,一个用于Paypal等…或者我们需要在另一个BC之前的sub-BC？
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.
是的,我同意模块和BC结构在书中没有得到足够的覆盖.我建议Implementing Domain-Driven Design by Vaughn Vernon了解更多.
Do Bounded Contexts contain modules or modules contain the Bounded
Contexts?
BC包含模块.一个模块就像一个轻量级的BC,也属于普遍存在的语言.
When an application has DDD,how easy it can be extendable?
这取决于你如何构建它.没有关于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中的模块.此外,您的付款处理模式和PayPal等第三方之间的每个整合都是ACL.
Or do we need sub-BC inside another BC?
不,但这触及了一个有意思的BC省.我不认为sub-BC是一个好主意,因为我认为分级组织可能是危险的导致刚性设计(例如,看看具有明确类型层次结构的OOP – 可能是有问题的).相反,选择可能更多BC的更平坦的模型.此外,在您的情况下,可以使用模块实现所需的结构化.
