PaloT wrote:
>
> Hi Patrik,
> I was playing little bit with new mongo-shipping sample. I like the
> concept a lot but we need to clean rough edges.
>
Thanks a lot for trying it and for your feedback. I'm very interested in
your ideas.
We need to keep it simple, at least for 1.9.
I don't think CQRS and EventSourcing is for everyone and all types of
applications. It is rather different from what most developers are used to.
It is often very application specific, and should be so. I think we can see
CommandEvent and its scaffold of EventSourcing as a help getting started
with that type of design, but in the end that must be designed for the
specific application. That area is definitely experimental state, and will
be so in 1.9.0.
DomainEvent and publish/subscribe is a lot easier, and has a much wider
usage. The idea is that you should be able to start with DomainEvent and
simple event bus, then adding integration product if you need, and so on..
PaloT wrote:
>
> Separation of layers
> is tooo unclear. When programming something like this we have to
> separate layers. Maybe via separate project or something else (any
> idea?). When I'm programing business tier Services I should work only
> with Repositories and Services of same module. When I'm programming
> orchestration tier or integration tier (any other good name for this
> tier above services?) I can use only commands and business tier
> services (no repositories) across different modules. Am I right? For
> now it's very unclear and confusing and not error prone for
> programmer. You have to be very careful what are you including in your
> services.
>
Sure, but we can't set too many restrictions on the design in sculptor,
since this event mechanism (publish/subscribe) can be used for so many
different things.
I can understand that the shipping sample is a bit confusing without any
documentation, since we have packed every feature in a single app.
PaloT wrote:
>
> I like your event handling but here are many duplicity even already in
> model. Can we simplify this somehow for example generating DomainEvent
> for each CommandEvent?
>
Yes, that is a possible future improvement. Right now you can "connect" them
like this:
CommandEvent RecordArrival extends @ShippingCommand {
- ShipId ship
- UnLocode port
}
DomainEvent ShipHasArrived {
- RecordArrival causedBy
}
PaloT wrote:
>
> What is proposed transaction model? Where transactions begins and ends
> (on service tier, on orchestration tier, ...)? Will we have some
> explicit compensation methods?
> Please also consider some explicit dead letter queue for commands
> which aren't processed (exception fired when processing event/command
> in default EventSubscriber handler).
>
Normally, CommandEvents are processed by synchronous method calls and
exception goes all the way up to the one that sent the CommandEvent,
rollback etc as usual.
DomainEvent are not intended to be part of the transaction scope. If the
subscriber can't process it, bad luck for him, but the sender should not
know. That reminds me of that I should add try-catch-log-continue in the
event bus.
PaloT wrote:
>
> Can we make similar sample without using mongoDB? This noSQL stuff is
> still strange and confusing for me and maybe also for others.
>
Sure, that is the intention. EventSourcing will not be as good, and you need
to implement some things manually if you need the same functionality
(especially replay to restore historical state).
Try it! Remove nosql.provider from sculptor-generator.properties.
If you don't need replay functionality you can add property:
generate.eventSourcing.replay=false
PaloT wrote:
>
> This concept is very import. I would like to make it right. Should you
> write somewhere generic concept before we start implementation. I know
> you are clever guy and you have something in mind but I would like to
> influence you (if possible ;-) that it should be more universal. I'm
> excited about it and maybe we aren't going to make it perfect for 1.9
> release but for 2.0 I would like to have it usable and integrated with
> at least one major SOA platform and tested with different
> configurations.
>
You can of course influence. This is a very good start for that.
I'm also excited about this and think it is key to scalable systems.
Thanks for your feedback.
/Patrik
PaloT wrote:
>
>
> We are stepping to integration tier with sculptor and it's very
> important for enterprise development. We already have some need for
> this in our projects and we can do it now in sculptor - great.
>
> 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
>
>
--
View this message in context:
http://old.nabble.com/New-sculptor-event-mechanism-tp29024456s17564p29028350.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
------------------------------------------------------------------------------
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
