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?)