I don't know exactly what you specifics you are referring to, but I
assume it is something like;

@Mixins( MyDomainComposite.class )
public interface MyDomainComposite extends EntityComposite
{
    String name();

    void changeName( String name );

    interface State
    {
        Property<String> name();
    }

    static abstract class MyDomainMixin implements MyDomainComposite
    {
        @This private State state;
        public void changeName( String name )
        {
            state.name().set( name );
        }
}


This is quite effective of hiding the State from clients. It requires
some really serious reflection to reach it, and you can't cast
MyDomainComposite to State, as the composite instance doesn't have the
interface in its Proxy.


If I remember the CQRS/EventSourcing disucssions some 1.5/2years ago,
the Command interface is public and the implementations of those will
do validations and any generation of 'values' that are needed (such as
Entity Identities, timestamps and so forth), and the internal (like
above) Event interface is in normal mode called from the Command
implementation, but a Record/Playback concern records the events, and
can be activated to play those back into the Event implementation
where the evolving business domain resides.

HTH

On Sun, Sep 26, 2010 at 4:58 AM, Marc Grue <[email protected]> wrote:
>
> Hi Streamflow developers,
>
> Can you help me understand why your roles have properties and event methods
> inside an inner interface? Is it to make those more private? If so, couldn't
> the environment just cast the role to the Data interface and get access
> anyhow?
>
> I haven't digged into your event sourcing implementation yet, but I suspect
> that the separation of normal method calls (createMessage) vs event methods
> (createdMessage) has something to do with the separation too...
>
> Cheers and thanks for any input,
> Marc
> --
> View this message in context: 
> http://old.nabble.com/Streamflow%3A-inner-interfaces-in-roles-question-tp29808298p29808298.html
> Sent from the Qi4j-dev mailing list archive at Nabble.com.
>
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>



-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to