title: Extensibiliy with DDD: Module Vs Bounded Context in DDD with MEF
body: <p>Eric in his book touches the subject of <strong>Modules</strong> 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?</p>
  
  <p>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.</p>
  
  <p>Let us take an example. In an e-commerce application, we can have a bounded context for <strong>Payment Processing</strong>. 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 <strong>Payment Processing</strong>. I can drop that dll in the application, and the MEF will auto discover it.</p>
  
  <p>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 <strong>Payment Processing</strong>. (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).</p>
  
  <p>How can we handle this extensibility problem with DDD? Is <strong>Payment Processing</strong>, a BC and different folders beneath it as modules, one for Paypal etc... Or do we need sub-BC inside another BC?</p>