CQRS as a Junior Developer
Fresh from university, searching for a development job, having one within two weeks. And at an interesting company at that. That is what happened to me about a year ago. So, you could (and probably should) call me a junior developer. After a month of trainings and new experiences I was put on my first big project. Together with a senior colleague we were assigned to build the new roadside assistance application at the ANWB. The app was planned to work with Axon at the core and through this I came in touch with CQRS
Since I didn’t know squat about the ‘Command-Query Responsibility Segregation’ concept and soon had to work with it, I dove into a multitude of sites, blogs and wikis about the topic for self-study. That it separates the responsibility of commands and queries is quite obvious from the definition itself. And that this leads to scalability options since the command or the query side can be optimized to the system, made sense. Also, that it simplifies the creation of the domain model since there can be a focus on either the command or query side was quite clear through the information I read.
Frankly though, I didn’t immediately grasp the feeling of what all this encompassed. What these advantages should mean to me as a new developer. The reason for this is not that it’s a dull or too complicated paradigm, but that next to trying to understand the CQRS-matter, I was also quite preoccupied with the fact that I was changing my life style from being a (relatively) lazy Computer Science student to a junior software developer, baffled by the amount of new impressions coming at him.
Evidently, it took me some time to understand the advantages of CQRS.
Luckily, constantly being in the loop of a project which uses CQRS makes the reasons for such an architecture more clear. Additionally, the ANWB project’s previous iteration also taught me why separating the command and query side was (in their case) a good idea. Many different services relied on results from the roadside assistance app, such as registering the state of a case, sending out purchase orders and several other manager-relevant services. The previous installment of the app had big time-consuming queries for these systems, which cluttered the code. Making relative small changes to the app was time consuming and dangerous, since you could potentially change something in a query the system somewhere completely else relied on. Thus not only development, but also performance eventually became an issue.
Separating the commands from the queries proved to be a big help for the new roadside assistance application. Modeling the application with commands and queries separated made development more streamlined and was actually quite straightforward (after the senior colleague I started with showed me a couple of times however). Also, the services are now separate optimizable parts of the system instead of being entangled, heavy queries throughout the code.
So, how do I experience CQRS as a junior? It is an interesting paradigm to use and over time showed me why in some cases it can be a very useful concept, as with the project described above. Additionally, the thought process still gives me new insights in how to approach problems. In short, it helps me, as a starting developer, to see how a big system should work.
As noted earlier, I came in touch with CQRS through Axon and gave me a good feeling of its concepts. Hence for the interested reader wishing to apply the CQRS principles, I’d advise the Axon Framework.
Other interesting reads I encountered concerning the topic are:
