.net implementation of communication between aggregate roots in different bounded context

Question

This is the first time I am applying DDD concepts to a real world problem.

I started with only 1 Bounded Context as the project is relatively small. However I found myself with classes that are almost identical i.e. very similar names, very similar properties but different behaviour. I am starting to think that they actually belong in different bounded contexts as the entities are the same and just have different meaning in a different context. This is supported by the fact that the application basically has two completely different user groups.

I have done a bit of reading on how two entities in different bounded context can communicate with each other. I think I understand the concept... but have no idea how to implement? Is there a .net example somewhere? i.e. an aggregate root in one bounded context publishing an event to an aggregate root in another bounded context? and also an aggregate root calling an aggregate root in another bounded context.

And should each bounded context have its own: service layer? repository and data layer?

Answer 1

This may help it is a quote from Implementing Domain Driven Design by Vaughn Vernon.

"Perhaps the most common use of Domain Events is when an aggregate creates an event and publishes it. The publisher resides in a module of the model, but it doesn't model some aspect. Rather, it provides a simple service to the aggregates that need to notify subscribers of the events."

Events are published using a service and implementation of the handler depends on the acceptable time for the rest of the model to be eventually brought consistent. With My particular requirements it is acceptable for a small delay in time. My domain events are published to a queue using MSMQ then in an external process I read from the queue and preform the work. This design allows me to offload this work to an external host and free up IIS. I use the same mechanism to persist the changes to storage. When the transaction on my aggregate is complete I publish a committed event to MSMQ and have 2 queues on a multicast. One queue for handling additional work and the other for persistence.

If you haven't read it already I highly recommend that book. I am sure my design will bring some criticism but your implementation will depend on your requirements and how comfortable you are with using eventual consistency.

Hope this helps and if you decide to use MSMQ here is a link to get you started. http://msdn.microsoft.com/en-us/library/aa480407.aspx

Here is my implementation of the domain event publisher.

public class DomainEventPublisher
{
    string DomaineEventMessageQueue = @"FormatName:MULTICAST=234.1.1.1:8001";

    public void PublishEvent(DomainEvent domainEvent, string correlationId)
    {
        MessageQueue eventQueue;

        eventQueue = new MessageQueue(DomaineEventMessageQueue);

        Message message = DomainEventMessage.CreateDomainEventMessage(domainEvent);

        message.CorrelationId = correlationId;

        eventQueue.Send(message);
    }

}

Answer 2

So I have 4 possibilities for you.

1. Re-visit your domain model: The fact you need to communicate between aggregates can indicate a problem with the model. The key here is that everything within a bounded context remains consistent but there are no guarantees between aggregates.

2. Use a process manager (or SAGA): Similar to the answer above you can respond to domain events and coordinate a cross aggregate communication from a process manager.

3. Inject a service: Be careful with this one as you want to put a premium no or few dependencies in your domain. Having said that it may still be the right or if not most pragmatic way to solve the problem.

4. Change your perspective: Do you already have the information from the other aggregate before interacting? If so can that be passed in with any command removing the need for the communication?

I go into a lot more detail in my blogpost on the subject. In case you find it helpful you can get to it from here: 4 Secrets to Inter-Aggregate Communication in a Event Sourced System