Yes, this is a small but extreamly important addition to Sculptor. Andreas and I have developed it together and used the knew mongodb/shipping sample as prototype. We have not written documentation yet, but here follows a short summary:
In the simplest form you need Observer pattern to decouple modules, swap direction of dependencies. When something happens in the core domain a notification should occur in supporting module (e.g. statistics). It is desired that core is independent of support modules. For this we have DomainEvent and a mechanism to publish and subscribe through a simple event bus. You need to communicate between bounded contexts (business components) in a loosly coupled way, possibly remote. E.g. send and receive messages with JMS. For this we have implementations of the event bus that integrates with Camel and Spring Integration. Same API as the simple event bus. It is also possible to mix our event bus with usage of ordinary endpoints provided by Camel or Spring Integration. The simple event bus use plain synchronuos invokations to notify subscribers. If you need asynchronous notifications that is easy to achieve with Camel or Spring Integration. The event bus API is extremly simple and you can easily plug-in your own implementation of the bus. We plan to integrate with Akka and maybe also directly with Redis. Additionally, we support CQRS by having separate definitions of CommandEvent, which is something that the system is asked to perform, as opposed to DomainEvent, which is something that has happened. EventSourcing is nice together with CQRS and we provide a default implementation of EventSourcing, which can be extended and customized to fit specific needs. It stores CommandEvents and dispatch them for processing. Dispatching is done via the event bus. It also provides mechanisms for replay of CommandEvents to reconstruct past state. /Patrik PaloT wrote: > > Hi Patrik, > I looked now to sources and you started "some" interesting changes > according CSC-520. Do you have more details what you plan or do you > want achieve? I guess CSC-520 is changing way how are we going to > develop applications with Sculptor in future. It also influence > middleware tier. Some BIG picture available on net or in your head ;-) > (something like > http://en.wikipedia.org/wiki/Event_Driven_Architecture)? > > Pavel > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > 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/CSC-520-tp28990047s17564p28990984.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer
