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?

Zosema

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.

Minnieminnnie

Answer 2

In DDD book, Eric Evans says:

BOUNDED CONTEXTS Are Not MODULES

The issues are confused sometimes, but these are different patterns with different motivations. True, when two sets of objects are recognized as making up different models, they are almost always placed in separate MODULES. Doing so does provide different name spaces (essential for different CONTEXTS) and some demarcation. But MODULES also organize the elements within one model; they don't necessarily communicate an intention to separate CONTEXTS. The separate name spaces that MODULES create within a BOUNDED CONTEXT actually make it harder to spot accidental model fragmentation.

My interpretation is:

• They are different things then you don't need to be worried about how many modules you have.
• BC contains Modules
• They are similar but have different motivations
• You can identify the BC name by the prefix of the module name, but don't need to

An example:

paymentprocessing.dataprovider.paypal.impl.http
paymentprocessing.usecase
paymentprocessing.entity
paymentprocessing.entrypoint.http

Entrypoint, usecase, entity, http, are not BC at all, they are modules. The prefix of the module, "paymentprocessing" is the BC. In my example I've organized the modules in a way that they are also organized by BC using the module namespace prefix, but even if they were in different application they still would be part of the same BC.

obs:

BC = Bounded Context

Glottal