October 13, 2026
As a briefly touched upon in the introduction article, I was really never happy with the original application's toward modeling activity. We inherited a mandate to migrate a Dec application (file system based) to an Oracle persistent store. Translating the schema was interesting, and deviating from the original model was considered high risk. Given the number of variables at the time, I see the merit in that approach.
Thank is not the case here, there is room for expirimentation, which I am taking advantage of.
There is a requirement to record what happened for each operation, however an additionaly we need to track event sequences. When something is introduced into a tank which already contains product, we need to locate what existing content was present, the state of the new content, in order to derive the new state of the content. Additionally, there are use cases that require that we may need to go back to a given point in time and determine every transaction that was impacted from that point forward. That would be the case for a product recall. Imagine if there was salmonilla suspected from oranges originating from a particular orchard, we would need to identify every tank of juice that contained oranges from that orchard and trace that product to the final packaged product that was shipped.
I found that this type of modeling was unique than other efforts I had experienced on previous projects. It makes things interesting. This also presents a challenge for scenarios where large series of related transactions are performed as we need to perform a data retrieval operation only to determine the next piece of data to retrieve, almost in an recursive manner.
This would be most clearly illustrated for cases where a product recall is issued. The system needs to be able to determine all transactions that were impacted from a given point forward. For example, if there was a batch of oranges that was contaminated with Salmonella, the system needs to be able to determine every tank of juice that contained oranges from that batch and trace that product to the final packaged product that was shipped.
In my personal experience, in coordination with ATF surprise audits, I was responsible for providing this type of information, in reverse order. So like, given this selected tank, how did it get to this state?
A common requirement for tank based applications is to be able to determine all activity related to a selected tank within a given period of time. So basically, from the point in time the tank was last empty at the current or at some previous point in time, there is a requirement to identify all activity from that point until the most recent recorded transaction, or until again it had assumed an empty state.
Let's take a look at the revised model.
This is an interesting point where the agent based approach does not have enough context to make recommendations on.
By default, the persistent models were generated as per instructed, however performing operations such as traversing related operations exposes a lot of lower level logic, which within a large code base can easily result in a lot of redundant code. While ORM is great at abstrasting otherwise SQL level persistence operations, you have a relatively flat representation of data, not always the most intuitive to work with. From an architectual perspective, it is advantageous in this case to abstract the rest of the consuming code base from these lower level details.
The solution is to wrapper calling functions within an abstraction, or more specifically an value object. One of the benefits of approaching problems is that we can wrapper data and expose convenience methods for various operations.