Recently domain driven design got my attention, and while thinking about how this approach could help us I came across the following problem.

In DDD the common approach is to retrieve entities (or better, aggregate roots) from a repository which acts as a in-memory collection of these entities. After these entities have been retrieved, they can be updated or deleted by the user, however after retrieval they are essentially disconnected from the data source and one must actively inform the repository to update the data source and make is consistent again with our in-memory representation.

What is the DDD approach to retrieving entities that should remain connected to the data source? For example, in our situation we retrieve a series of sensors that have a specific measurement during retrieval. Over time, these measurement values may change and our business logic in the domain model should respond to these changes properly. E.g., domain events may be raised if a sensor value exceeds a predefined threshold.

However, using the repository approach, these sensor values are just snapshots, and are disconnected from the data source. Does any of you have an idea on how to solve this following the DDD approach?


I think you need to separate out your areas of concern as they really are separate. Considering them together just muddies the picture.

First, you have the representation of your SCADA / monitoring data and the periodic refreshes that will be required for it.

Second, you have the generation of events based upon sensor readings.

Most SCADA systems that I've worked with have some mechanism to periodically poll the data source in order to refresh the display. You'll need a similar mechanism for your application. This doesn't violate DDD, as DDD's focus is how the data is mapped to the domain not in how often it is retrieved.

Generally, sensor reads are a read-only type thing but overwrites may be necessary. To allow for the overwrite, you'll need to keep track of the timestamp(s) associated with the changed value(s). You'll need some function to then overwrite within the data store, or alternatively write to another table that has preferential retrieve access to the original values. Again, this doesn't violate DDD.

For the second aspect, you'll need some sort of event monitoring agent. Following a DDD approach should help you here. Having the data schema align with the application structures as well as the business logic will make it easier to update rules as necessary. I suspect your business object environment will be reasonably static so you won't have to worry about accommodating structural change all that often. I imagine you'll have tweaks to alarm thresholds and / or new combinations of data streams for analysis.

Long answer short - DDD doesn't preclude any of the concerns you bring up. It's more about how you structure your data.

  • I'm not sure if I can follow you entirely. You mention that DDD does not preclude changes to the domain model from outside. Should I regard the source of data updates as a user, i.e. should I add an eventmonitor in the presentation layer and let it periodically do something like SensorValues.Refresh(newData)? – fstuijt Nov 21 '12 at 14:54
  • As a user, no, you don't care about the updates. It's actually the domain that drives the need for the updates. Monitoring data is inherently ephemeral, and an operations view only cares about what the current values are. In and of themselves, those updates have no effect upon the model so I don't understand why you're asking about changing the model. Depending upon the language you use, a Refresh() function would work or an Event monitor or a timer would work. – user53019 Nov 21 '12 at 19:28

To answer the question it would be helpful to know the consistency model appropriate for the application. Would eventual consistency suffice? In other words, how "connected" does the data need to be? Also, what type of storage technology is used? A relational database? A NoSQL database with weakened ACID constraints?

One of the issues is that as soon as data is read from the database into memory, there is already potential for inconsistency, unless a write-lock is issued. However, in your case, a write lock cannot be issued because the data needs to be updated from another source. Therefore, you have to embrace eventual consistency because there will be a delay between when sensor data is updated and when that information reaches the domain code.

If eventual consistency is acceptable, then you can implement a message handler which listens for sensor data and invokes the appropriate domain layer code, which may in turn raise domain events. This message handler is in a sense outside of your domain layer - it is an infrastructural/application layer concern. It is very much like a message handler in something like NServiceBus or MassTransit, the only difference being that the underlying storage mechanism is different. (Although if MSMQ or ZeroMQ is suitable for the application you can just use those).

  • We use an external SCADA system that provides us with the snapshot values of the sensors. Following your explanation I think eventual consistency will suffice for our solution. Thank you for your input. – fstuijt Nov 21 '12 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.