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 examp

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.