A spell ago I become interested in CQRS pattern and I was seeking for
useful frameworks to use in my projects.
I was looking over some frameworks, including Axon Framework, and I
found many interesting things.
And in my opinion, Axon Framework conform to DDD concept most of all.
It’s lightweight and easy to use.
In addition, the implementation of Command Handler Interceptors,
Snapshotting, Event Bus and Event Listeners have an advantage over
another decisions.
However I have a problem, I’m a .NET framework developer and I can’t
use Axon Framework in my project.
I’d like to porting this framework to .NET. What do you think about
it?
I will take it as a compliment that you wish to port Axon to .NET. Ola already pointed out one, but there is quite a number of .NET frameworks for CQRS out there. I haven’t checked any of them out, as .NET is not my piece of cake. Are you sure not one of them has a similar view on the CQRS and DDD?
Axon is currently under development. If there was a time to port Axon to .NET, I don’t think this is the best time to do so. It would only mean that two similar code bases need to be maintained continuously, each with their own capabilities and challenges.
On the other hand, Axon is open source. You can do with the code as you like (only limited by the very few restrictions the Apache license has). So if you want to use any of the design principles in another framework, I don’t see any problem. But I’d rather see it as an Axon-inspired framework than a .NET port. Calling something a .NET port will add extra expectancies from end users in regard to support and maintenance that you might not really want to cope with. And unfortunately, I would have the knowledge nor the time to provide substantial help in that area.
If you have any further questions, please don’t hesitate to drop a note.
Yes of course, we looked at Ncqrs framework.
There are many interesting things which we like, especially an using
of attribute for mapping command and their handlers.
However, we didn't like that in realization of Aggregate Root was used
UnitOfWork and Repository respectively.
In my opinion, this is destroy the principle of DDD Persistent
Ignorance.
Moreover, the Axon Framework uses some things which we didn't find in
this frameworks.
For example, class VersionedAggregateRoot with optimistic locking
mechanism;
the list of base classes for creating an own aggregate
(EventSourcedAggregateRoot, AggregateRoot, etc);
some repositories (standard Repository and Event Sourcing
repositories);
Snapshot mechanism ( and as far as I understood the version
0.6 of Axon Framework has a feature to trigger snapshot creation based
on the number of events needed to load to reconstitute an aggregate).
Hello, Allard. Thank you for the reply.
Some reports on DDD Exchange 2010 were stimulate us to look for a
decision of CQRS pattern. And our team became looked for a different
frameworks, which support of CQRS architecture. We found out that Axon
is the most acceptable, but Java implementation is a restriction in
use for us. Our team will convert Axon code from Java to .NET a few
days, and a few days for Unit testing in addition. Besides that, we
use our DDD Infrastructure Framework in our projects, which contain
all necessary building blocks for application development with classic
DDD architecture.
I have a question relating to Axon Framework porting. Now I see 2
variants of code porting:
1. Create a particular solution with name Axon.net, for example, where
the code will full conform the original Axon code.
2. Porting most part of Axon code to our framework. In this case we'd
use our implementation of Repository and some other blocks, for
example UnitOfWork. If we have a possibility we'd like to make an open
source, with all the consequences.
my preference, at this moment, will go to your second option. Doing a full .NET port of Axon as it currently is just doesn’t sound like a very good idea to me. There is quite a lot of Java-specific JVM trickery going on in some parts of the framework that might be hard to translate to .NET. And Axon is still under development, which would mean that instead of one, two codebases must be maintained at all times.
Sounds like we need to set up a .Net dev team. Any volunteers?
The framework has matured significantly since the discussion has started, so the context has changed a little. As stated before, I am nowhere near knowledagble in .Net development, but I am able to provide information about my vision on CQRS and frameworks (incl. API design).
I’ve been working on an Axon-inspired framework (well to be fair it’s got influences from a number of libraries out there) but unfortunately its under NDA. I’d be happy to help with a .Net port though.
from our end, nothing has changed on this. We’re not planning to create a .NET port of the framework. I also haven’t heard of one being made by a third party, so far.