Using Domain-Driven Design (DDD) to separate the concerns of a large system into bounded contexts with each context using its own data store often results in a need to share some common data, Julie Lerman recently explained in MSDN Magazine.
When Julie, a Microsoft MVP since 2003, began learning about DDD, she struggled with the duplication of data such a separation could result in, but an explanation by Eric Evans, author of the original DDD book, cleared things up:
You have to choose where to pay the price of complexity. Because DDD is about reducing complexity in the software, the outcome is that you pay a price with respect to maintaining duplicate models and possibly duplicate data
With each bounded context having its own database, there are a number of different ways to leverage common data but Julie focuses on one scenario, mirroring data from one bounded context to another with one system owning and designed for editing the data and a second system just needing read-only access to a part of that data.
In an example Julie describes a scenario with one system, System A, dedicated to customer service, maintaining customers as well as plenty of other data. Her second system, System B, deals with taking orders with a need for read-only access only to customer names and identifiers.
Instead of system B exposing methods for creating and updating customers that when used by System A would cause a synchronous dependency, Julies uses an event-based approach using a message queue to implement the publish-subscribe pattern. System A will then publish events by sending messages about created and updated customer, messages that system B listens to and updates its database. Using this technique system B will end up having a complete list of customers but only with a small amount of data compared to system A.
Julie calls a system that enables transfer messages in an asynchronous way an event bus, containing the infrastructure to store and send messages including an API for interaction. For her example she uses RabbitMQ, an open source message queue.
Julie has made the code for her implementation of the example available for download.
In a blog post 2012 Udi Dahan wrote about transactions and the problem of incorporating some queueing systems like RabbitMQ into the database transaction to avoid inconsistencies in a system.