Extensibiliy with DDD: Module Vs Bounded Context in DDD with MEF

Question

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?

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.

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.

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).

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?

Answer 1

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.

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.

Do Bounded Contexts contain modules or modules contain the Bounded Contexts?

BCs contain modules. A module is like a lightweight BCs and also belongs in the ubiquitous language.

When an application has DDD, how easy it can be extendable?

That depends on how you architect it. Nothing about DDD itself would prevent extensibility.

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?

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.

Or do we need sub-BC inside another 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.