The situation. Let’s say a background process puts stuff into data containers. It runs all the time, observes system events, and populates the data accordingly.
The user may launch a control panel application. With this application, the user can define new containers, rename or delete old ones. The panel is separated from the actual workhorse process to not accidentally take it down when it crashes.
For the sake of the example, let’s assume the background process increases a counter for each container by 1 every minute. It’s a lifetime counter. It needs to know about the containers. It’s the only process which modifies the counters, though.
The control panel should display a list of containers and the current count. It should update a displayed count when needed (i.e. when the counter changed in the meantime). It needs to read the data but not write it — except maybe for mutating the set of containers.
The question. Both processes operate on a similar domain. Both need to know about containers and counts. They only do different things with them. Now how would you model this in terms of DDD?
I pondered if they were different Bounded Contexts, but since the domain seems to be exactly the same, there’s no indicator that this is necessary. The separation between both is merely technical. Maybe do some kind of RPC?
How should the processes share data? Should the control panel become a read-only process, access the same data store the background process writes to, and delegate container creation to the background process so writing is unified? (Is this CQRS already?)
Use a pub/sub framework like nServiceBus. The control panel can subscribe to update events on the domain model. The background process will emit the update events. When the control panel first starts up, it will send a command to the background process to tell it to send all the info it needs.
Messages will contain serialized domain objects. The framework deals with making sure they get there. For example with nServicebus you can use MSMQ and be on separate machines (of course or the same one but here I’m assuming the control panel is running on a webserver and the update process is running on an app server).
Now for updates, the control panel can send commands via the bus to the update process, reflecting what update is wants. Same idea, serialize some info and put it on the bus. The UI can then block (OK give the poor user a throbber) until the next update message is received. Or, it can have an ‘update pending’ message in the header area that turns into ‘refresh’ or actually has the UI refresh (watch out if the user is onto something else…)
You might not want to throw all these new infrastructure pieces into your shop. But standing up pub/sub (inversion of communications SOA pattern) gives you so many options, you’ll jump for joy.
3