----- Original Message ----
> From: Rickard Öberg <[EMAIL PROTECTED]>
>
> "RIGHT", as in, an "object" actually has two parts to it: the internal
> part, such as CargoState, which represents "what the object is" and then
> the roles/mixin types that represent "what the object does", and where
> the roles are defined by the contexts and usecases rather than the
> object itself. In common modeling these two would be mixed into one,
> which is why the getter/setter problem exists. In Qi4j the raw access to
> properties is ok, but ONLY within the roles of the object, i.e. they are
> not exposed to clients of the object. This I think is one of the key
> insights here!
>
In the dddsample the domain objects are concrete classes and are instantiated
directly whereas the DDD approach would be to use Factories to separate out the
implementation of the objects.
Is this what you are referring to?
Is that all that you are referring to?
The terms 'roles' and 'mixins' are, afaik, never mentioned in the DDD book.
I understand what the term 'mixin' means in Qi4J (you are adding interfaces to
an object's implementation) but I'm not sure about 'role'.
When you say "In common modeling these two would be mixed into one, which is
why the getter/setter problem exists." that implies to me that you intend for a
Qi4J aggregate to be able to implement more than one domain interface, perhaps
with the same accessor methods.
In Qi4J does a 'role' only apply to the implementation layer? Or to the domain
layer also?
That is, does Qi4Jenable an object to switch domain roles depending on the
context it is being used, like in 'role-based modeling'?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
