Thanks for your reply:)

As you adviced I ran through the "Choosing your Model Context Strategy" chapter.

Just to make sure I understand your thoughts: do you mean that: objects'
archetypes are relative to the (application) context, in which they collaborate
with each other? and if there are too many archetype candidates then probably
the (application) context is too wide and should be narrowed?

For instance Student is a role within the course registration domain but
probably a moment-interval within the attending-the-university domain
(registration, deregistrtaion, payment, etc.). Thus the two domain should be
separated (?).

Or am I missing something again?:)

Cheers
Gyula

--- In colormodeling@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> You are correct. Colors are defined by the relationship of the object with
> others ... collaborations. Yet there is usually a color that is dominant.
>
> If there is not dominant context you might be mixing to many contexts. Check
> Evans book about bounding contexts.
>
> Nuno
>
>
> On Tue, Oct 27, 2009 at 10:23 AM, Gyula <csomgyula@...> wrote:
>
> >
> >
> > Hi everyone!:)
> >
> > Having some experience in modeling, though limited in color modeling I have
> > a question which seems typical for me:
> >
> > (At least for me) it seems that everything is changing and bound to time:
> > things, parties and descriptions, too. And in many cases (office-like,
> > auditing, etc.) systems has to preserve the older record versions and many
> > of them needs to store time data. How does this effect colour modeling?
> >
> > For instance take the Student Registration domain:
> >
> > From one viewpoint the Adress is a thing, from another it's a
> > moment-interval (for instance the street can be renamed resulting in
> > different address versions for the same place). How should one model this
> > situation? What will be the archetype of an address version?
> >
> > From one viewpoint the Student is a role, from another it's a
> > moment-interval ("being a student" has a start and end date). How should one
> > model this situation? Should we split the student entity into a role- and a
> > moment-interval entity, introducing unnecessary complexity? Or should we
> > merge them introducing an entity having two different archetypes.
> >
> > Any idea? Anyone who met similar situations?
> >
> > Cheers,
> > Gyula
> >
> >
> >
>