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.
2
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).
1