won*_*rld 22 domain-driven-design
埃里克在他的书中很少涉及模块的主题.他也没有谈到模块结构与有界上下文的关系和例子.有界上下文是否包含包含有界上下文的模块或模块？当应用程序有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另一BC里面？
eul*_*rfx 24
埃里克在他的书中很少涉及模块的主题.他也没有谈到模块结构与有界上下文的关系和例子.
是的,我同意模块和BC结构在书中没有得到足够的覆盖.我建议由Vaughn Vernon实现域驱动设计以获取更多相关信息.
有界上下文是否包含包含有界上下文的模块或模块？
BC包含模块.模块就像一个轻量级的BC,也属于无处不在的语言.
当应用程序有DDD时,它可以扩展多么容易？
这取决于你如何设计它.DDD本身的任何内容都不会阻止可扩展性.
付款处理,BC和它下面的不同文件夹作为模块,一个用于Paypal等......或者我们是否需要在另一个BC内的sub-BC？
我会将每个支付处理器集成建模为单个支付处理BC中的模块.此外,每个集成都是您的支付处理模型与第三方(如PayPal)之间的ACL.
或者我们是否需要另一个BC内的sub-BC？
不,但这涉及一个有趣的概念,即子BC.我认为sub-BC不是一个好主意,因为我认为分层组织可能是危险的,导致严格的设计(例如,查看具有显式类型层次结构的OOP)可能会有问题.相反,选择具有更多BC的更平坦的模型.此外,在您的情况下,可以使用模块实现所需的结构.