I'm not authorized to go into details, so I try other but similar samples.

1. Say you have a weather forecasting company. You run a central system which
stores weather forecasts per geolocations (latx, laty, forecast) which then
published onto the Internet. This is the operational side of your business.

Say you also run some quality assurance. Thus you have some employees whose role
is nothing but to measure real world temperatures. They go out to the country,
make and register measurements, then go back and load the results into the
central system, where the data is then postprocessed, eg. the central system
compares the forecasts against real world measurements, evaluates the
differences, reports on them, etc. In order to do this you have to store
temperature data as timestamped records on both sides (central and mobile),
otherwise you cannot compare them.

Hmm this is not the best example. so I try another...

2. You have a financial system with complex rules to manage and control credits.
A guy comes into the bank asking for some credit. The process takes 1 month
(this is a very very big credit application:)), but unfortunately the bank
declines the credit so the guy becomes bankrupt.
After 1 month the guy's friend (having the exact same financial conditions as
the original guy) requests the same credit and after 1 month he is approved. So
the original guy goes back to the bank to kick up the row:)
What happened? The credit approval rules changed. Can the bank simply resolve
the issue with the original guy? Yes if it preserved the original rules, then it
could tell this fact.

In my point of view the bank can preserve the rule data in two different ways:
within the process (by taking-and-copying a snapshot) and outside the process
(by versioning the rules). Which solution should one prefer? I guess this is not
a functional issue, but a technical one. Making a snapshot for every credit
approval process could result in a very large database. Meanwhile if the rules
change frequently the versioning solution could again result in a very large
database. But again I could be wrong:)

Cheers,
Gyula

--- In colormodeling@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> Hi Gyula,
>
> > Thus when postprocessing someone's work results, the system must
> > work against the master data that was valid when the work was
> > executed.
> >
>
> I suggest you to have a look at the Event Sourcing pattern to capture
> events from the mobile system.
>
> > Hence the system must preserve older versions of master data.
> >
>
> I understand the need to preserve older versions. Again I would
> suggest event sourcing not only in the mobile but also in the master
> system.
>
> Yet I don't think necessarily needed re-run the captured events
> against the same object state (data).
>
> > The person downloads the master data from the system to his
> > workspace, goes out,
> >
>
> Consider that when the user does this it creates a new temporal branch
> or parallel model if you will. When the user comes back what you want
> to do is re-conciliate operations/changes on both sides.
>
> Assuming that there were no software upgrades on both sides, what you
> want to be sure is that events captured from the mobile system don't
> collide with events made on the master system.
>
> Say if you changed the name of a person (PersonAddressChangedEvent) in
> the mobile system when synching back you want to check if someone did
> the same, and if so you want to give the user options to resolve the
> situation.
>
> Does this make sense?
>
> Nuno
>