Related
So I'm a bit new with CQRS (not totally a beginner though). I'm trying to understand the best practices when it comes to aggregates interaction. I read a bit about using Integration Events (instead of Domain Events) in these situation, also a bit about Domain Services (that would supposedly link the 2 aggregates) but couldn't find any good definitive answer anywhere (especially not on the axonIQ Getting Started guide
Also another not too related question is that in layered architecture usually we have the controller directly linked to a service and this service can interact with other services (or repos) while with CQRS the controller is usually sending a command to the aggregate. So if my api call needs to interact with 2 aggregates do I have to build a middle-man service that would send commands (or listen to events) from the 2 services?
The interaction between components in a CQRS system can happen on a couple of levels.
On way to think about it is as Maxime suggest, with Microservices, very clearly showing the messaging focus of it all.
Regardless though, this can just as simply happen within one Application/Monolith which has several Aggregate types that together need to trigger some operation.
I feel that Maxime is providing you the answer you need. The Aggregate instances which you send commands to, act on their own and do not tie in to one another directly, at all. You'd thus react on the events as the driving force the start an interaction between both.
You can either do this by having a Event Handling Component which listen to both the events and performs the business transaction you're dealing with.
If the business transaction is a little more complex, looking at Saga's might be a good start.
Lastly, you state the 'Getting Started' part of the Axon Reference Guide is not clear about this topic. I think that's a valid conclusion, as from Axon's perspective this is not part of the Getting Started. Take a look at the Saga portion of the guide to get an idea of the interaction between Aggregates and/or Bounded Contexts.
If you think of this in term of microservices (which is a philosophy that fits CQRS very well) you should have one aggregate for one microservice. So you can't communicate between aggregates in memory because they're not part of the same process. A good way to do it is by using events that you can publish in a event bus. So the client send a command to "aggregate A" using the API of this microservice (i.e. "microservice A") (or maybe an API gateway). Then "aggregate A" is saved and the events generated by "aggregate A" are published to the event bus so that some process (aka. event handler) in "microservice B" can catch the event(s) and send the appropriate commands to "aggregate B".
It's just one way to do it there is many more and it can be very more complex than that, but I hope it's helping getting the big picture.
Suppose I have a very large-scale server-side web application written in JavaEE (and related technologies classically combined with it), and I decided to migrate it completely to Akka (and related technologies usually combined with it, including moving the code to Scala). The reasons of the migration decision are not important: suppose I have to do it, and that's all to it.
My question is: What would be the strategy to follow here, aiming to optimize the migration time and the scalability of the resulting application?
If the question lacks of details, I can provide some, although I would like to hear strategies without being very specific.
This is an open ended question. But let me try and give you some ideas. Having worked with both J2EE as well as Play2/Akka/Spray.io (Scala) based system I can provide you will the following high level/general guidance for migration.
Partition your system: Partition your current system based on functionality and rank them according to their criticality to business, your stakeholders and clients. Partitions can done based on different dimensions ( architectural components at runtime, business features, development team/modules) etc. You also need to find dependencies between these partitions.
Identify candidate partition: Once you have ranked partitions, it’s useful to pick the smallest possible partition that overlaps in as many dimensions as possible and has the least amount of coupling. Usually this is the case if your initial architecture is modular.
Implement a prototype: Take the candidate partition and create a prototype that provides the same functional capability. Now evaluate and compare the new capability against the old in terms of various quality attributes (performance, modifiability, extensibility etc). The prototype will also give you an estimate of technical risk, challenges, and effort.
Create a new architecture: I think at this point you should have enough input to create the first version of your new architecture. Also identify how capabilities of other partitions will be implemented in this new architecture. Selecting the most complex partition and try to map it to this new architecture is really good exercise and can massively reduce your technical risk in the future.
Field the prototype: Try to field the prototype to a small subset of users/stakeholders and get feedback. Decoupling the prototype using REST/pub-sub interfaces is a good idea.
Plan for migration: Create a plan and schedule for rest of your system.
I can be more specific if you provide more targeted questions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As part of researching CQRS for use with a project, I ran across the Axon Framework, and I was wondering if anyone has any real life experience with it. Just to be clear, I'm asking about the framework, not CQRS as an architectural pattern.
My project already uses Spring and Spring Integration which fits nicely with Axon's own requirements, but before i dedicate a lot of time to it, I would like to know if anyone has some first hand experience. In particular I'm interested i possible pitfalls that are not immediately apparent from the documentation.
The framework relies heavily on eventsourcing, which means that all state changes are >written to the data store as events. "
This is completely untrue, it does not rely heavily on event-sourcing. One of the implementations for storing the aggregate in this framework use Event-Sourcing but you can easily use also the classes provided to use a standard relational model.
It is just better with event-sourcing.
So you have a historical reference of all your data. This is nice but makes changing your >domain after you've gone in production a very daunting proposition especially if you sold >the customer on the system's "strong auditability" "
I don't think it is a lot easier with a standard relational model that only stores the current state.
The framework encourages denormalizing your data, to the point that some have suggested >having a table per view in the application. This makes your application extremely >difficult to maintain, especially when the original developers are gone"
This is unrelated to the framework but to the architectural pattern in use (CQRS).
And sorry to mention that but having one denormalizer/view is a good idea as it stays a simple object.
So maintenance is easy because SQL request/insertion as also easy.
So this argument is not very strong.
How about a view which uses a 1000 tables model with inner joins everywhere and complex SQL queries?
Again, CQRS helps because, basically, the view data is just a SELECT * from the table which correspond to the view.
if somehow you made a mistake in one of the eventhandlers, your only option is to >"replay" the eventlog, which depending on the size of your data can take a very long >time. The tooling for this however is non-existent.
I agree on the point that currently there is a lack of tooling to replay events and that this can take a long time. However, it is theoretically possible to only replay a portion of the event and not all the content of the event store.
Replaying can have side effects, so >developers become scared of doing it
Replaying event have side effects -> that's untrue. For me side effects means modifying the state of the system. In an event-sourced CQRS application, the state is stored in the event-store. Replaying the events does not modify the event store.
You can have side effect on the query side of the model yes. But you don't care if you have made a mistake because you are still able to correct it and replay the event once again.
it's extremely easy to have developers mess up using this framework. if they don't store >changes to domain objects in events, next time you replay your events you are in for a >surprise.
Well if you misused and misunderstand the architecture, the concept, etc. then ok I agree with you. But perhaps the problem is not the framework here.
Should you store delta's ? absolute values ? if you don't keep tabs on your developers >you are bound to end up with both and you will be f***ed
I can say that for every system I would say that it's unrelated directly to the framework itself. It's like saying, "Java is crap because you can messed up everything if someone codes a bad implementation of hashCode and equals methods."
And for the last part of your comment, I already seen samples like helloWorld with the Spring framework.
Of course it is completely useless in a simple example.
Be careful in your comment to make a difference between the concept (CQRS + EventSourcing) and the framework. Make a difference please.
Since you have stated that you want to use CQRS for your project (and I assume that the JVM is your target platform) I think Axon Framework is an excellent choice.
I have built a fairly complex trading platform on it (no, the trading sample is not complex) and I have not seen any obvious flaws of the framework.
Since I use EventSourcing, the test fixtures made it very easy to write BDD style "given, when, then" tests. This lets you treat an aggregate as a black box and concentrate on checking that the correct set of events come out when you put in a certain command.
About pitfalls: before jumping in, make sure
That you have the concepts of CQRS figured out.
Make a list (paper, whiteboard, whatever) of all your aggregates, command handlers, event handlers, sagas, commands and events. This is the hard part of building your system, figuring out what it should do and how. After this, the reference manual should show you how to wire it all together with Axon.
Some non Axon specific points:
Being able to rebuild the view store from events is a concept of EventSourcing, and not something that is exclusive to Axon, but I found it pretty easy to create a service that will send me all events from an aggregate type, aggregate id or a certain event type.
Being able to build a new reporting component one year after the project is launched and instantly get reports on data from the time of the project launch and onwards is awesome.
I've been using AxonFramework for more than one year on a complex project developed for a big bank.
The requirements were demanding, customer's expectations were high, and release times narrow.
I've choosed AxonFramework because, at the project kick off moment, it was the most complete and the best documented implementation of CQRS available in Java, well designed, easy to integrate, to test and to extend.
After more than one year I think that these considerations are still valid and current.
Another consideration has guided my choice: I wanted that the commitment on such a difficult project to become a training opportunity for me and other members of the team.
We started to develop with AxonFramework version 1.0 and moved to version 1.4 as newer versions were released.
Our team experience with CQRS and the implementation provided by the AxonFramework was absolutely positive.
It provided us with a consistent and uniform manner to develop each feature that guided us and make you feel at ease.
Without it some features of the application would have been much more complicated to develop.
I am referring mainly to the various long-running processes that need to be handled and to the related compensation logic, but also to the many business logics pieces that have been necessary, here and there, that fitted nicely and uncoupled in the event driven architecture promoted by CQRS.
Our choice was to be conservative in the write model, so we preferred a JPA based persistence instead of the event sourced one.
The query model is made up of views. We have tried to make sure that each view contains all the required data from a single page using intermediate views when necessary.
Anyhow we developed the write model as we were applying event sourcing, so we take care of modifying the state of aggregates exclusively through events. When the customer asked for a cloning function of a very complex aggregate it was just a matter of replaying the source events (with uuid translated) to a brand new instance - the down side in this case have been the events upcasting (but this functionality was greatly improved in the imminent 2.0 version).
As in each project during the development we found a lot of bugs, in our code mainly, but also in components supposed to be mature and stable, like the application server, the IoC container, the cache, the workflow engine and some of the other libraries that are easily to be found in any large J2EE application.
As any other human product AxonFramework was not immune to bugs too, but surprisingly for a young and niche project like this, they have been few, not critical, and quickly resolved by new releases.
The kind and immediate support provided by the author on the mailing list is another invaluable feature and helped me a lot when I was in trouble.
The application was released in production a year ago and is currently maintained and under active development of new features.
The customer is satisfied and asks for more.
When to use AxonFramework is more a matter of when to use CQRS. For a response it's worth to go back to the official documentation: http://www.axonframework.org/docs/1.4/introduction.html#d4e51
In our case definitively it was worth it.
The OP specifically asks about the pitfalls relating to the Axon Framework rather than CQRS. This makes the question difficult to answer, as Axon started as a fairly faithful implementation of the famous book by Eric Evans
The main advantage is that it does exactly what it says on the tin: it handles the hard parts of a CQRS based design for you: aggregates, sagas, event sourcing, command handlers, event handlers, BASE consistency etc. When you follow the best practices, you end up with a highly responsive and horizontally scalable application. If you use it with event sourcing, your data is completely auditable, and at least in theory, you can determine the state your application had at any given point in time. Tooling to do this is not provided; you will have to roll your own.
The main developer of the framework is very approachable and extremely knowledgeable on the subject of high performance and scalable computing in java. He tends to answer every question on the mailing list within a few hours. This is both an advantage and the major pitfall: at this time (early 2014), the Axon Framework depends heavily on one person. The rest of the pitfalls I would like to mention are probably more the result of event sourcing than of CQRS or Axon (as of 2018 the framework is supported by the company Axoniq)
Design your data model very carefully upfront. Though it is easy to add to, making fundamental changes to your datamodel can be very difficult. If you make a fundamental mistake in the datamodel, your application may not perform well, or even fail to work at all. For example, if you choose a tree shaped data model, with one long lived aggregate root at the top, this aggregate may grow very large as it accrues more and more events over time, and it may take a long time to load and store. I don't know what will happen if this goes on until an instance of the aggregate no longer fits in RAM, but I imagine could be bad. Don't do it that way.
Another pitfall (event sourcing related) is that, after a number of revisions, it can become increasingly difficult to reason about the state of an aggregate, as you sometimes have to keep in mind not only what the code does today, but also what it did in the past. This definitely makes replaying (a portion of) the event store to rebuild a view table a non trivial task.
Fixing data errors can be more difficult than with a 'traditional' design. Rather than a simple SQL statement, you will often need to make a command to change the state of your application. If the error in your data was caused by a faulty event handler, you can usually just fix the bug, clear the snapshots and let he events for the aggregate be replayed. If your bug caused spurious events to be applied, it can me much more trouble to fix. The faulty events will stay in the event store, and you may have to apply some new ones to restore your data to the correct state, or change the code to ignore or fix their behaviour.
While the framework itself is written decent enough, using it in a real world project has been nothing short of a nightmare and the choice of this framework imo was a major contributing factor to this project's failing.
The framework relies heavily on eventsourcing, which means that all state changes are written to the data store as events. So you have a historical reference of all your data. This is nice but makes changing your domain after you've gone in production a very daunting proposition especially if you sold the customer on the system's "strong auditability"
You cannot have ops guys make ad-hoc changes to the database
The framework encourages denormalizing your data, to the point that some have suggested having a table per view in the application. This makes your application extremely difficult to maintain, especially when the original developers are gone
if somehow you made a mistake in one of the eventhandlers, your only option is to "replay" the eventlog, which depending on the size of your data can take a very long time. The tooling for this however is non-existent. Replaying can have side effects, so developers become scared of doing it
it's extremely easy to have developers mess up using this framework. if they don't store changes to domain objects in events, next time you replay your events you are in for a surprise. Should you store delta's ? absolute values ? if you don't keep tabs on your developers you are bound to end up with both and you will be f***ed
There is practically no adoption of this framework, so googling for answers will not do you any good
Even though the framework does not yet support distribution it's written with it in mind and the api's are a pain to work with because of it. Firing off an event is async by default and if you want to check if an exception was raised executing the command, say a duplicate username exception, you need to pass in a listener to your commandhandler which is a future, then you wait for the future's result to come in, handle any checked exceptions, interuptedexception etc and then you can grab the exception that was thrown from the future. Ofcourse which exceptions a command can raise is not apparent from the api. Defeating the purpose of checked exceptions
Check out some of the example apps. I somehow need a unit of work listener to create an addressbook application? My goodness...
I am currently with a team working on an online casino platform launching our brand Casumo this summer. The domain and platform is build using Axon Framework and so far it it has served us solidly.
A lot of time has been saved not having to build all the infrastructure needed for command handling, event routing, event sourcing, snapshoting etc and the APIs are really nice to work with. The one bug we found in the framework so far was fixed in .. release 12 hours later and Allard is always quick to take suggestions on new features and discussing ways to leverage the framework to fulfill your needs.
Building a client-side swing application what should be notified on a bus (application-wide message system, similar in concept to JMS but much simpler) and what should be notified using direct listeners?
When using a bus, I always have an unescapable feeling of "I have no idea who uses that and where". Also, no set order, hard to veto events, hard to know exactly what's going on at a set time.
On the other hand, using listeners means either directly referencing the source object (coupling) or passing the reference through myriad conversions (A--b_listener-->B, B--c_listener-->C only because a needs to know something only C can to tell, but B has no interest in).
So, are there any rule of the thumb regarding this? Any suggestion how to balance?
In my experience, trying to make Swing do something it wasn't designed for, or doesn't want you to do, is extremely painful.
I would go with the simplest thing that would work; keep your code clean, do it the "Swing Way" until you start seeing problems.
Event buses are very, very useful tools for providing decoupling in certain architectures. Listeners are easy to implement, but they have significant limitations when your object and dependency graph gets large. Listeners tend to run into problems with cyclic dependencies (events can 'bounce' in odd ways, and you wind up having to play games to ensure that you don't get stuck. Most binding frameworks do this for you, but there's something distasteful about knowing that listener events are shooting off into a million places).
I make this kind of decision based on project size and scalability. If it's a big app, or there are aspects of the app that can by dynamic (like plugin modules, etc...) then a bus is a good way to keep the architecture clean (OSGI-like module containers are another approach, but heavier weight).
If you are considering a bus architecture, I recommend that you take a look at the Event Bus project - it works very well with Swing and provides a robust, out of the box solution for what you are asking about.
The convention in Java Swing is to use listeners heavily. Sticking with the convention improves maintainability but stifles innovation.
I've not encountered the bus approach in Swing, but I find it interesting.
Well, I can imagine the approach where models are updated using BUS like system and events from models are delegated using listeners. Simple scenario: I got server side which represents producer of data. Then on client side a got consumer interface which consumes all incoming messages and transform them into my internal messages/DTOs and push them into bus which distributes them into application model(s). These model process incoming messages and decide to notify interested components using listeners.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have recently been exposed to naked objects. It looks like a pretty decent framework. However I do not see it in widespread use like say, Spring. So why is this framework not getting any mainstream application credit. What are its shortcomings as you see?
From my experience using NOF 3.0.3...
The good:
Automagically generates an DnD UI for your domain objects, like what db4o does for persistence.
This is what MVC was always meant to be, according to the MVC pattern creator.
The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.
The framework favors convention OVER configuration: lots of annotations no freaking XML config giles.
Works great for prototyping along with db4o for persistence.
Out of the box functionality for Hibernate.
In my case, I required like 30 mins from Download to Hello world app. (IntelliJ IDEA IDE)
Deployment as JNLP, standalone, Web (NOX embedded Jetty or Scimpi flavor) and Eclipse RCP.
The NOF team is ALWAYS there for you when you ask for help in the forums.
The Naked Object Pattern is an awesome idea, do yourself a favor and take your time to grok it.
Theres a lot of usability flaming going on around the Drag and Drop GUI, but if your prospective end users simply can't work with the DnD UI then you are in deep trouble anyway.
The bad:
None that I can think of.
The kinda ugly:
No Swing components allowed, so say goodbye to JGoodies and all your favorite Swing component sets. The UI components are custom made; to get you an idea they look like early 90's VB controls. But there's a SWT port in the works.
The multiline line field for long strings has some issues. (NOF 3.0.3)
DnD UI for images is kinda buggy.
The validation code for getters n setters only fires if the domain object is modified from the UI. (This is probably wrong due to my n00bness, lets hope a NOF committer corrects me)
If an object is modified from a non-ui thread, lets say a b.g. worker, such object will
not update its view on screen. This invalidates a use case such as representing a mail queue in real time on the DnD autogenerated UI. (Again)
Veikko
I've been working on the naked objects approach for over a year now and I haven't even begun to scratch the surface of the possibilities it provides for your system's architecture. To properly utilize it though, it requires that you create a paradigm shift and seek out full OO solutions and revert from resorting to functional duck tapes, because the paradigm seems to work only when you create a design that would allow for high-level development.
Having said that, I absolutely love how Django has implemented naked objects within it's Django Models. Most of the things I love about the framework have been, what I come to believe, a direct result of it's models and there are some wows off the top I'd like to share about the architecture:
Model fields, that map to table columns, are behaviorally complete objects--they know how they're represented in both the application and database domain, how they're converted between the two and how the information they hold is validated and displayed to the user visually for inputs. All of this utilized with a single line of code in your model. Wow!
Managers are attached to models and provide CRUD and any generic operations on collections, such as reusable queries (give me the last five blog posts, most occuring tags, etc.), mass delete\update operations, and business logic performed on instances. Wow!
Now consider you have a model that represents a user. Sometimes, you'd only like to have a partial view of all the information a user model holds (when resetting a user's password you may only need need the user's email and his secret question). They've provided a Forms API that exactly displays and manages inputs for only parts of the model data. Allows for any customization of the what/how in handling user input. Wow!
The end result is that your models are only used to describe what information you use to describe a particular domain; managers perform all the operations on models; forms are used for creating views and for handling user inputs; controllers (views) are only there for handling HTTP verbs and if they work with models it's solely through managers and forms; views (templates) are there for the presentation (the part that can't be automatically generated). This, imho, is a very clean architecture. Different managers can be used and reused across different models, different forms can be created for models, different views can use different managers. These degrees of separation allow you to quickly design your application.
You create a ecosystem of intelligent objects and get a whole application from the way they're interconnected. With the premise that they're loosely coupled (lot's of possibilities for letting them communicate in different ways) and can be easily modified and extended (a few lines for that particular requirement), following the paradigm you really do get an architecture where you a component write once and then reuse it throughout your other projects. It's what MVC should have always been, yet I've often had to write something from scratch even though I did the same thing a few projects ago.
It has been successfully used here in Ireland.
I think reasons why it hasnt been more popular are:
You need a lot of confidence in the toolkits you are using
It makes the GUI a risk factor instead of a no-brainer (both technically and in usability testing)
Its not applicable to the web (as far as I know), which is where most of the focus is as present...
I've only just seen this. A couple of minor corrections, otherwise most of the comments are very fair.
1) 'The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.'
Naked Objects does not require the domain objects to be subclassed from AbstractDomainObject, although that is typically the most convenient thing to do.
If you don't want to inherit, all you need to do is provide a property of type IDomainObjectContainer, and the framework will then inject an container into your objects when they are created or retrieved. The container has methods for Resolve(), ObjectChanged() and NewTransientInstance(), which are the three minimalist points of contact with the framework that you must use, so that the framework remains in synch with your domain objects.
2) 'Works great for prototyping along with db4o for persistence'. We're quite keen on the idea of working with db4o, but I'm not aware of anyone who has made Naked Objects and db4o play together. If anyone has done this, I'd like to hear more about it.
3) 'The general model of citzen programmer as espoused in the smalltalk and naked object communities ...'. We have never espoused that idea, and I don't agree with it. Naked Objects is NOT about encouraging users to program. I believe firmly in the role of the professional developer - Naked Objects just helps them to write better software and more productively.
Richard
I have played with it last year or so, and concluded it is very easy to work with.
The strength of Naked Objectsis that you get a GUI structured according to your data model for free. The disadvantage is that a typical user does not think about his proces as a collection of records.
My conclusion was that Naked Objects is really great for an internal application which conceptually deals with records, like an inventory application or bill processing application.
If you need anything different adapting the framework to your wishes may just be a lot more work than using a framework written to support the kind of application you want.
By the way, there is a Web rendering option; see the demo at Naked Objects Demo.
Gareth makes some excellent points.
There are other issues, such as the fact that it's hard to control the look and feel, and they are counter-intuitive to people who have become used to the window model. There is also something of a modelling issue, in that not all application domains lend themselves well to direct oject representation.
The general model of 'citizen programmer' as espoused in the smalltalk and naked object communities also comes to bear as a questionable idea. Most users don't seem to be hugely bothered with changing the functionality themselves, so thinking in objects is not that useful.
Probably the reason it hasn't gotten more attention is that the J2EE world has become so used to piling on so many layers onto an application, that naked objects comes across as naive.
Where are our services? You mean that any naked object gives me immediate access to the database? What if we needed to expose the application with RMI calls?
Plus there isn't as much to market, because it puts the burden of developing a successful application squarely on the application developers not the framework developers :)
I guess NakedObject definitely has its relevance and its more than time that developer community refocuses on what is really paying them: the business.
Instead, we mostly spend our time with infrastructure, protocols and all that technical crap. I have seen such miss constructed applications and I even did some myself following the mainstream, teaching you that layering a system is always a good thing to do. The worst thing is that if you ask some developers about what kind of business the company they are working for does, you’ll find at least some who worked for the company for years without gaining a deeper understanding of the business.
However, I don’t believe that NakedObject will attract a vast majority of developers (even those who are inspired from DomainDrivenDevelopment) simply because people love to construct UIs and taken that job away from them, directing their work towards businesses needs, is simply not what they want: We are all VB jerks.
NakedObjects (NO) are good for rapid prototyping. You can concentrate on Domain Model while not paying attention to GUI, DB and other parts of your solution. For production it requires alot of improvements (bugs fixing, data mapping, gui, etc.) in NakedObjects framework itself.
So if you need to get some kind of "proof of concept" for your solution, you may use NO. But for production be ready to invest resources into development of NO framework.
BTW, recently we are working on creating DnD viewer based on GWT for NO 4.0.
widespread use of technology has no strong correlation to technological quality.
The nakedobject system is difficult to use in combination with type objects:
if I'm selling different kinds of products and need different data for different products, it is difficult to constrain the data on the product type.
NO lost momentum when they switched licences. (to GPL+Commercial, not the recent move to Apache)
Did you take a look at jmatter?
[edit]
And another one: it makes it obvious to non-programmers if you can deliver. Spring is very much in the technological domain, NO means a developer has to talk to users. Large organisations don't do that.