Take the 2-minute tour ×

Each of our bounded contexts has an event message processor which pulls messages off the inter-context-bus and dispatches it locally via an in-memory bus (Reactive Extensions, or https://github.com/flq/MemBus).

In DDD books I have read it talks about putting messages in modules within the project such as mycompany.accounts.infrastructure.messages and mycompany.ordering.infrastructure.messages .

The problem for me with multiple contexts, referencing these messages would lead to circular references.

How best to organise different bounded context messaging contracts:

  1. Would each bounded context have a separate project that contained all of the possible messages for that context so that other bounded contexts could reference?

  2. Or is it better to have separate shared library for all messages that will go over the inter-context-bus?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

I solve similar problems building (at least) two assembly for each bounded context:

  1. One for the contracts (event, exceptions, shared identifiers and so on...)
  2. One for the implementation of entities.

This way, different bounded contexts implementations can reference to the same contracts, without any cicle.

As for naming conventions, I usually name assemblies after the "conventional name" of the bounded context, for example

  1. BankName.FinancialAdvisory for the contracts
  2. BankName.FinancialAdvisory.POCO for the implementations
  3. BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName when I need to specialize some class to use them in a specific technological environment.

However, inside the POCO assembly the root namespace is the same of the contracts' one (eg BankName.FinanicalAdvisory): this because the POCOs, that expresses the business rules in code without any technological concern, have the same development livecycle of the contracts. On the contrary the assembly containing technological specializations uses a root namespace that is equals to the assembly name (such as BankName.FinancialAdvisory.ORMOrOtherTechnologicalCouplingName).

Nevertheless all the assembly related to the domain share the same namespace structure: for example if a namespace "Funds" exists under BankName.FinancialAdvisory it also exists in both POCO and ORMOrOtherTechnologicalCouplingName (if it contains any class, of course).

share|improve this answer
Thanks - any recommendations on namespaces? –  g18c Mar 27 '13 at 11:11
Just edited the answer to explain how I organize namespaces. –  Giacomo Tesio Mar 27 '13 at 11:49
Just to throw back what I saw today, channel9.msdn.com/Blogs/Subscribe/… very interesting, a different view in that we are more liberal with messaging and not concrete contract types - your answer is certainly very helpful in that clearly shows how to link projects should you wish to have closer coupling –  g18c Mar 30 '13 at 14:20

Your Answer


