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.
Community comments
Interesting article
by Daniel Whittaker,
too much data centric ideas
by Nuri YILMAZ,
Re: too much data centric ideas
by Jan Stenberg,
Interesting article
by Daniel Whittaker,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have only recently published a post on a very similar topic. I looked 4 approaches to achieving inter aggregate communication but made the assumption that the service/application was following an CQRS and ES approach. The post can be found at: 4 Secrets to Inter-Aggregate Communication in a Event Sourced System
Thanks again for the article - very helpful.
too much data centric ideas
by Nuri YILMAZ,
Your message is awaiting moderation. Thank you for participating in the discussion.
subject is "sharing data" so we think that all related with data. I don't think so. J.Lerman excatly use terms as MS SQL Server seller. You can share data on many ways but it is subject of database system (rdbms, nosql etc). Code should be seperated by data source. so why we discuss sharing data between bounded context?
Re: too much data centric ideas
by Jan Stenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
If you share data using the same database or by replicating data between two DBs you have created a dependency between the systems sharing that data. This may later on evolve into more than one system updating the shared data, which gives you even tighter dependencies. By separating systems/bounded contexts, systems listening to changes in the master system can have their own models, and can evolve independently, thus decreasing the dependency.