Features at record level : what does it mean?
I sometimes explain that one of The-Data-Box interesting characteristic is to have its features managed at the record level. But what does it mean exactly? As I often find myself in trouble to explain this clearly, I’ve decided to make 2 small pictures that summup the difference between common applications and The-Data-Box. First, here is, in a very simplified way, a common application paradigm :
In short, the application manages a collection of features that interact with application data.
This model has at least two consequences :
- If you add or delete a feature from the application, all the data is impacted by this change
- The data is not aware of what’s happening at the higher level : for example, if a record is following a workflow, and suddenly this workflow was deleted from the application before the end of the process, then the record becomes dead, or at least it falls into a non-consistent state (unfinished workflow).
With The-Data-Box, the central idea is to keep data self-consistent and state-consistent.
To achieve the state-consistent goal, we plug the features at the record level, like this :
This principle has many advantages :
- A record is aware of the features it uses
- A record is the guardian of its own state regarding these features (for example : a record could start its workflow in a system A and go on its workflow in a system B)
- Deleting a feature which is currently in use by one or more records will not happen because each record provides a lock mechanism over the feature(s) it uses. Here is what’s happening in The-Data-Box if you try to delete a feature used by some records :
In another article, I’ll try to explain how The-Data-Box records are also self-consistent.