First of all let me just say thanks for this framework. Looks really
great
I'm considering using the CQRS pattern for a project that aims at
creating a platform for various teams to use. Each team will have it's
own business requests and therefore should be able to enhance the
functionality of the platform without impacting others.
I believe that using CQRS is a radical mind shift from how we're used
to do development, but one that would allow us to have an architecture
that isolates features instead of modules.
Even more, with such a design features should be "plug and play"
because as they all revolve around a core flow, the only thing they
need to do is to "tap" into the appropriate events to perform their
duty.
First of all, has anybody heard of any examples of CQRS being used
with such an objective (feature extensibility in a shared product)? It
would be great to provide as support when pitching the idea as this
implies a big change for all our developers.
Secondly, I was thinking of taking this "feature boundaries" concept a
step further and use OSGI in doing so. I envision a system were we
could have a core bundle that manages the main commands, aggregates
and events of our domain, and have additional bundles that would
expose/register additional commands, events, and event handlers that
add incremental functionality to the system.
The main objective of using this approach is that once you reach this
level of isolation, features become really plug and play and if one
team wants a certain feature developed by another team they only need
to deploy that feature bundle.
Do you have any thoughts on this? Prior art?
Finally, I see that there's a MongoDB implementation of the Event
Store and I was wondering if anybody is working on a Cassandra
implementation?
I ask this because I believe that for the particular use case of event
storage, Cassandra might be a better fit as this implementation could
be a lot more robust in case of a SplitBrain problem in your storage
cluster.
personally, I like the API of event-driven CQRS applications: just commands and events. And it’s that clean API that makes this architecture very suitable for extensible applications. Unfortunately, I haven’t yet had the opportunity to create one with the type of extensibility you are talking about.
As “bph.lib” said in his reply, it might be a good idea to post the extensibility question on dddcqrs as well. Someone there might have done this before and come up with pointers. Though my gut feeling sais it should be too complex (not more complex than OSGi with a “regular” architecture).
The Axon library itself isn’t set up as an OSGi bundle, but it’s probably not too hard to convert it into one. Dynamically registering and unregistering command handlers and event handlers shouldn’t be a problem either. Concurrency has been taken into account in those methods.
Concerning the mongo event store, it was just the start of an investigation for faster ways to store events. I just set up a small taskforce to figure out what the most suitable storage system would be. Perhaps Cassandra.
personally, I like the API of event-driven CQRS applications: just commands and events. And it’s that clean API that makes this architecture very suitable for extensible applications. Unfortunately, I haven’t yet had the opportunity to create one with the type of extensibility you are talking about.
As “bph.lib” said in his reply, it might be a good idea to post the extensibility question on dddcqrs as well. Someone there might have done this before and come up with pointers. Though my gut feeling sais it should be too complex (not more complex than OSGi with a “regular” architecture).
Thank you both for the pointer, I’ve already subscribed to the other list, and will send the questions there shortly.
The Axon library itself isn’t set up as an OSGi bundle, but it’s probably not too hard to convert it into one. Dynamically registering and unregistering command handlers and event handlers shouldn’t be a problem either. Concurrency has been taken into account in those methods.
Indeed, I don’t see too many problems with doing this, but of course, I’m not yet too familiar with the Axon FW. I think that probably the biggest pains would be related to marshalling/unmarshalling of Events defined in other bundles as ClassLoader management tends to be a little painful.
Concerning the mongo event store, it was just the start of an investigation for faster ways to store events. I just set up a small taskforce to figure out what the most suitable storage system would be. Perhaps Cassandra.
Great, please keep us informed. One important thing to keep in mind there (this may be obvious, but sometimes it doesn’t get enough attention) is how SiteOperations-friendly is the backend and how well does it behave during disaster and during disaster recovery. Anyway, sorry if I’m just stating the obvious and was already in consideration. But we developers tend to think in terms of our own “realm”
when using Axon in combination with OSGi, make sure to make separate bundles with your commands, events and shared model. This will prevent classloading conflicts. It’s a general design practice in OSGi, though, to separate API from implementation. You shouldn’t get too much trouble there…
Disaster recovery is definitely one of the criteria for being “production ready”. That’s why I focused on the JPA implementation first of all. Relational Databases are a proven technology, still highly preferred by many organizations. I’ll keep you up-to-date when I’m venturing in the more innovative sections of storage technologies…
