SV: SV: Modeling properties and associations explicitly

I definitely missed the cleverness 

This will work fine, as long as you trust the client not to cast anything
and access methods on the implementing class! This should not be a problem
since there is always a 'zone of trust' where you don’t expect evil clients
- and this code will definitely execute within such a zone.

/Tomas

-----Ursprungligt meddelande-----
Från: domaindrivendesign <at> yahoogroups.com
[mailto:domaindrivendesign <at> yahoogroups.com] För Rickard Öberg
Skickat: den 19 december 2007 14:27
Till: domaindrivendesign <at> yahoogroups.com
Ämne: Re: SV: [domaindrivendesign] Modeling properties and associations
explicitly

Tomas Karlsson wrote:
> *** My note *** This looks a little like Ruby on Rails, and I really
> like your proposal. If you introduce ReadableProperty, I think it
> should be possible to change from within the entity – but not from
> external code. (I don’t know how this can be solved in Java?)

This is entirely doable with the help of dependency injection and a 
little cleverness. Like so:
interface Order
{
   ReadableProperty<int> totalPrice();
   void addLineItem(LineItem item);

Object revision and relationship history tracking

The domain that I'm modeling requires complete object revision 
history and recall. This in itself isn't too difficult and many 
patterns exist for doing this both in databases and in instance 
objects. The difficulty is in tracking changes to relationships along 
with changes to values. To further explain my problem, here are a few 
domain objects*:

[Products] 
[Assembly Robots]
[Tasks]
[Task Results]

*These aren't actually my domain objects, but are actually a much 
simpler version.

All three have data members such as names, weight, frequency etc. A 
product requires that certain tasks are always performed on it such 
as checking every 100th one for correct weight. The robots also 
require tasks to be performed on them such as oil changes. Some tasks 
are only required when certain robots run certain products such as 
changing robot gripper sizes. When tasks are performed the results 
are entered into the system as task results. Tasks are therefore in a 
many to many relationship with both Products and Robots. 

The tricky part comes when a new task is assigned to a product or an 
old task deleted or modified. Say for example that on Monday the 
weight check task is changed to every 200th product, then on Tuesday 
removed completely. Providing a list of currently required tasks is 
simple. Reviewing historical records requires not only the Task 
Results but also the assigned Tasks for that day to determine if they 

Re: Object revision and relationship history tracking

Do you actually need to store the data in this way? Would storing
original objects + deltas be acceptable? Using this model you would
store an original version and a current snapshot ... you can build an
object representing any intermediate step by re-applying your deltas
to your "original" version. One nice benefit to this is that you also
have full auditing / rollback /etc built right in.

Cheers,

Greg

On Jan 3, 2008 4:22 PM, woil <ws <at> primedigit.com> wrote:
>
>
>
>
>
>
> The domain that I'm modeling requires complete object revision
>  history and recall. This in itself isn't too difficult and many
>  patterns exist for doing this both in databases and in instance
>  objects. The difficulty is in tracking changes to relationships along
>  with changes to values. To further explain my problem, here are a few
>  domain objects*:
>
>  [Products]
>  [Assembly Robots]
>  [Tasks]
>  [Task Results]
>

Re: Object revision and relationship history tracking

> There are a number of potential ways to solve this problem but none 
> of the application architecture or design pattern books that I've 
> reviewed have a means that I've liked

Prior to replying further I wondered if among your reading was Fowlers 
temporal patterns:

http://martinfowler.com/eaaDev/timeNarrative.html

 

Re: Object revision and relationship history tracking

For simpler situations than yours I'd suggest looking at the command 
pattern.  For example you could treat changing the number of required 
check tasks as a single command with undo and redo capabilities.  
Then you could either role back your application to an earlier state 
or roll forward the data from a saved checkpoint.

But because of your sentence "Reviewing historical records requires 
not only the Task Results but also the assigned Tasks for that day to 
determine if they were performed properly to the standards on that 
day. "  I think your requirement going to require you to come up with 
a more complete temporal object model.   

For example you may have develop an domain object lik "Standards on 
that Day" and then build it into you domain model.   If your users 
are going to be "Reviewing Historical Records" then you probably need 
use cases and a domain model that includes the 'Review Historical 
Records" activity.

--- In domaindrivendesign <at> yahoogroups.com, "woil" <ws@...> wrote:
>
> The domain that I'm modeling requires complete object revision 
> history and recall. This in itself isn't too difficult and many 
> patterns exist for doing this both in databases and in instance 
> objects. The difficulty is in tracking changes to relationships 
along 
> with changes to values. To further explain my problem, here are a 
few 
> domain objects*:
> 
> [Products] 

Re: Object revision and relationship history tracking

On Jan 4, 2008 12:22 AM, woil <ws <at> primedigit.com> wrote:
> The domain that I'm modeling requires complete object revision
> history and recall. This in itself isn't too difficult and many
> patterns exist for doing this both in databases and in instance
> objects. The difficulty is in tracking changes to relationships along
> with changes to values. To further explain my problem, here are a few
> domain objects*:
>
> [Products]
> [Assembly Robots]
> [Tasks]
> [Task Results]
>
> *These aren't actually my domain objects, but are actually a much
> simpler version.
>
> All three have data members such as names, weight, frequency etc. A
> product requires that certain tasks are always performed on it such
> as checking every 100th one for correct weight. The robots also
> require tasks to be performed on them such as oil changes. Some tasks
> are only required when certain robots run certain products such as
> changing robot gripper sizes. When tasks are performed the results
> are entered into the system as task results. Tasks are therefore in a
> many to many relationship with both Products and Robots.
>
> The tricky part comes when a new task is assigned to a product or an
> old task deleted or modified. Say for example that on Monday the
> weight check task is changed to every 200th product, then on Tuesday
> removed completely. Providing a list of currently required tasks is
> simple. Reviewing historical records requires not only the Task

Re: Object revision and relationship history tracking

There's yet another way -- forgive me if the following has already
been discussed.

The Temporal Object pattern: http://martinfowler.com/ap2/timeNarrative.html

I've used a variation of this to great success in a high request
environment.  We made the subjects and their relationships temporal.

Hope this helps - Jon

On Jan 4, 2008 3:24 AM, Daniel Yokomizo <daniel.yokomizo <at> gmail.com> wrote:
>
>
>
>
>
> On Jan 4, 2008 12:22 AM, woil <ws <at> primedigit.com> wrote:
> > The domain that I'm modeling requires complete object revision
> > history and recall. This in itself isn't too difficult and many
> > patterns exist for doing this both in databases and in instance
> > objects. The difficulty is in tracking changes to relationships along
> > with changes to values. To further explain my problem, here are a few
> > domain objects*:
> >
> > [Products]
> > [Assembly Robots]
> > [Tasks]
> > [Task Results]
> >
> > *These aren't actually my domain objects, but are actually a much

Re: Object revision and relationship history tracking

By the way, this book contain good information about handling history
tracking at database side

http://www.amazon.com/Database-Tuning-Principles-Experiments-Troubleshooting/dp/1558607536

On Jan 4, 2008 11:21 PM, Jonathan Harley <jdharley <at> gmail.com> wrote:
>
>
>
>
>
>
> There's yet another way -- forgive me if the following has already
>  been discussed.
>
>  The Temporal Object pattern: http://martinfowler.com/ap2/timeNarrative.html
>
>  I've used a variation of this to great success in a high request
>  environment. We made the subjects and their relationships temporal.
>
>  Hope this helps - Jon
>
>
>
>  On Jan 4, 2008 3:24 AM, Daniel Yokomizo <daniel.yokomizo <at> gmail.com> wrote:
>  >
>  >
>  >
>  >
>  >

Re: Object revision and relationship history tracking

Thanks to all of you for your help. I hadn't read teh TemporalObject 
patterns yet, and I think that they might help. I'd already figured out 
something similar, but seeing it written out can help. Fowler's PoEAA 
and Hohpe/Woolf's Enterprise Integration Patterns both didn't have 
these so I hadn't seen them yet.

In looking at some of the links posted, I found this:
http://sql-info.de/sql-notes/developing-time-oriented-database-
applications-in-sql.html

Which allowed me to download the book referenced by Martin 
Fowler "Developing Time-Oriented Database Applications in SQL". It 
looks a little old, but I dought much has changed since 2000 as far as 
the SQL is concerned.

I'm most concerned about the relationship tracking issues, but perhaps 
the book will help with that.

 -Will
primedigit.com

 

Domain Modeling Struggles with Persistence