On Wed, Jul 21, 2010 at 9:53 PM, Patrik Nordwall <patrik.nordw...@gmail.com> wrote: > PaloT wrote: >> >> Than after event reply aren't some events duplicated (one from replay >> and one from service)? >> > I'm not sure that I understand the question. > If you are using EventSourcing and the replay mechanism it is always the > CommandEvents that are replayed and if they result in additional > DomainEvents to be published they will be published again during replay. > This can definitely be unwanted and must be handled by the application. > Fowler describes this issue and talkes about gateways that must be aware of > replay mode and avoid interaction with external parties. Currently we have > not done anything about this. Can't we "tag" event that it's reaction event and than we don't have to store/reply it? This mean, framework will handle it without necessity to write specific code in application. We can also store for example module name which created event and events coming from system which is replaying event will be not replayed. I guess we can make something what will result in higher quality of EDA and mechanisms which will work better in "default" mode.
> PaloT wrote: >> >> If we can't fire CommandEvent from service do we have some well know >> patter which will bridge two services - for example service will fire >> DomainEvent and some integration code will generate CommandEvent as >> reaction to DomainEvent? >> > That is possible to do. We will write more examples in the blog. I can imagine with existing infrastructure but I guess this is higher level logic than Service. It's integration or orchestration code. I guess we have to split somehow this code from standard services and apply some constraint about this code. Something like - not possible to inject such kind of "service" to standard service (you can't call it from standard service), or maybe more strict and disallow injection of services to integration layer and allow invoking services from integration layer only with Events. It will also mean that such events and integration code will be invoked in another technical transaction, ... Many things appear in my hand which could be useful and necessary if we want use it in enterprise environment. >> Don't we have to store some information about event like >> module/application where it was created, ... for replay? >> > The EventSourcing mechanism operate on CommandEvents, which are persistent > and stored with the ordinary persistence mechanism in Sculptor, i.e. in the > same db as the business component where the specific CommandEvent is > defined. This was meant for better reply mechanism which can use this information and work better out of box. >From my experience, we have to find way how to layer services and way how to constraint communication between this layers. I mean something like this: http://en.wikipedia.org/wiki/File:SOA_Metamodel.svg In our system we have everything as Service. It's not bad, it's more flexible but in enterprise environment we have to layer and constrain service invocations. I would like to see it explicit in our DSL. Regards Pavel ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer
