Ted Stockwell wrote:
> 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?
Nope, it's more complex than that. See below.
> 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'?
Yes, you're on the right track. The point is that there are two point of
views of an objects: its own and how others view it. It is pretty much
free to define itself any way it wants, but that is not then directly
useful for clients in different contexts. A client defines a context and
a usecase where objects can play different roles. The client is
therefore the one that decides what interfaces it wants objects to
implement. This is in contrast to the naive way objects are typically
defined, where the object itself decides what its interface looks like,
and how it is accessed. When a client uses that interface it becomes
tightly coupled to that particular object type, which is bad. If instead
the object has to implement the interface that the client dictates there
is much less coupling.
In Qi4j there is then a natural way to do this: the object itself, with
its state and methods, are implemented in private mixins. Then the roles
it can play, i.e. the usecase interfaces it implements, are declared in
the Composite type (i.e. the Java interface that extends *Composite).
Both the roles ("what the object does") and the internal state ("what
the object is") is in one logical object rather than split up as would
be the case in traditional OOP, with the use of design patterns to get
around this limitation.
In Qi4j there is also an additional level to this since client code can
ask for a base type (e.g. "CargoEntity") but get a more specific subtype
if one is declared (e.g. "ShippableCargoEntity", or something like
that), where the subtype adds the role interfaces for that module/layer
only. This makes it possible for one entity to exist in many different
contexts with different roles for each context, if necessary.
Makes more sense now?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
