On a general scale, it would be command-query separation taken further -
that means having ImmutableQuery role interface which allows passing
something onto client code and having almost-near-to-absolute confidence
that the client code really won't be able to modify anything (as long as
nothing in ImmutableQuery itself won't be modifying anything). Otherwise
there wouldn't be much point in having IQ-role at all - if client code
could just cast it back into "original" role and do whatever changes it
likes.
If that's what you want to do, then you could consider using extended
composites instead.
Basically, you could have one composite for query like so:
interface QueryableDomainEntity
extends SomeQueryRole, EntityComposite
{}
Where SomeQueryRole refers through @This to your Data interface, which
has the Properties/Assocations/ManyAssociations. The Data interface will
be considered a part of the composite, since it's reachable from the
explicit roles using the @This injection.
Then you can extend it with your mutable composite interface:
interface CommandDomainEntity
extends QueryableDomainEntity, SomeCommandRole, SomeData
{}
Where SomeData is optional, as it exposes that interface outwardly, and
SomeCommandRole would be referencing SomeData using a @This injection as
well.
In your query layer declare QueryableDomainEntity so that a lookup of:
uow.get(SomeQueryRole.class, "123")
will return the immutable entity and in the command layer declare
CommandDomainEntity so that a lookup of:
uow.get(SomeCommandRole.class, "123")
will return the version with both commands and queries.
The lookup of the command version can be cast to the queryable version,
but not the other way round.
Is that good enough?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
