On 2010-09-26 04.58, Marc Grue 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?
The way we have done it now, yes it could. Niclas showed a way to avoid it. We like that we can go to the entity definition and see what state it has, so it's a tradeoff.
For Steamflow in particular we have recently figured out how to get it to be more DCI-oriented, which I think will fix this to some degree. Basically the context in the application layer will be defining the mixins with the commands, instead of like now when they are defined in the domain layer. I'm actually playing with this setup now, and when combined with CQRS/EventSourcing and REST API's as frontend it becomes pretty amazing.
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...
Right, we want one set of mixins to have domain logic only (the commands in the mixins called by the REST layer), and one set to have the state manipulating methods (events). When the above is done it will be even more clear, as they will be in different physical files and layers.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
