AxonIQ

Axon Framework 4.11.0 was released today! As usual, minor releases of all extensions and the bill of materials have also been made available. Although the vast majority of our development time flows towards 5.0.0, this release still includes a couple of worthwhile additions. First and foremost, we now support serialization through Avro. You are thus now able to provide Avro schemas of your messages and use them in Axon. Note the support is only present for messages! Lastly, I would like to thank Simon Zambrovski and Jan Galinski for the effort they've put into this. They saw an opportunity to provide this amazing contribution and took it; thanks, Simon and Jan! Besides the Avro Serializer, we've seen another practical contribution. This time around from Roald Bankras. He introduced an integration with Spring Security, both as an interceptor or directly annotated on message handlers. To be frank, I have been suggesting this type of support to users as a custom-built addition. Having it provided by Axon Framework is nothing short of awesome. So, thanks for this addition, Roald! Another contribution I would like to highlight is the auto-configuration for interceptors. Christian Thiel figured this would be an easy introduction into Axon's Spring integration. And he was right; the changes for this were straightforward. Put very practical nonetheless! Henceforth, thanks for the time and effort you put into this, Christian! The last feature I want to mention is our team's addition of handler timeouts. In short, you can now define when a handling thread should be interrupted. This can be configured globally, per message type, or per message handler. Furthermore, a timeout can also be defined for the unit of work. Hence, Axon can now interrupt a batch of events when it is blocked or extremely slow. This feature can, for example, unblock halted or slow 3rd party integrations. Hence, it should help any Axon application to run more smoothly. There are, of course, more than these four changes in Axon Framework 4.11.0. Do check the release notes down in the comments for an exhaustive list. Before closing, let me mention all remaining contributors to this release: • Alexander Praegla • Kursat A. • Weronika Trzaska Thanks in advance for all of your time and effort, both those who contributed and those who will use this release!

Event Sourcing "Friday FUD" - Messaging in distributed systems is hard. How can event sourcing alleviate the pain? Not everyone knows rule number one of distributed systems, and the rest don't abide by it: "Don't!" There is a joke about distributed messaging that shows the challenge quite well: There are three challenges in distributed systems: 1. Exactly once delivery 3. Message ordering 1. Exactly once delivery Given the right architecture and infrastructure, those problems are pretty easy to work around. One example is using some form of streams rather than message queues. Queues are notoriously bad for their delivery guarantees since the delivery responsibilities are scattered among consumers and producers. That fine-grained coordination of activities across two systems is simply impossible to get right. For Event Streams, this is slightly different. The responsibility for processing and guarantees resides in the client. As a bonus, Event Streams that are built up from event sourcing are also guaranteed to be correctly ordered, complete, and "eternally" available. This makes it easy to deliver any message the client believes not to have received. The client can start processing events at any given position that reflects its last known processed Event. Maybe those Events have been delivered before, but the client failed to process them. It doesn't matter. The goal is to process all events exactly once. This perhaps sounds trivial and logical. And for Events, this makes a lot of sense. However, I've seen systems implement Command and Query semantics using these same patterns. And that's where things get very awkward. Neither queues nor streams make very good building blocks for these types of messages. With Queries, there certainly is a component waiting for an answer. How long should it wait for a response? Might it be waiting in vain because there is no component available to answer to the query? If a response doesn't arrive, does it make sense to send the query again? After all, it will be queued after the previous instance. Commands generally cause side-effects and there is a user (or other system) on the other side of the line waiting for a confirmation whether the command has been executed on. When using a queue or stream-based system, redelivery of this command may mean that the command is executed again, and the side-effect happens twice. That can be problematic. Event Sourcing makes it much easier to make Commands idempotent. After all, any side effects are stored in the event stream. The command handler can correlate the incoming command with already available actions and just acknowledge the command without causing any side effects again. Does that make distributed systems trivial? No, it doesn't. However, using the right tools and techniques will make dealing with them much easier in the long run. There are enough challenges in software. Let's focus on the ones that really make a difference.

🌹Roses are red 💙 Violets are blue 🎫 All my events 💞Get sourced to you This Valentine’s, we’re making event sourcing easy: 3 months of free AxonIQ Academy. No fluff, just hands-on learning for event-driven pros. Claim your access now: https://hubs.li/Q036J8g70

“We're building something that other states can learn from.” Indiana DWD didn’t just modernize—they rewrote the playbook. While others relied on slow, fragile systems, this team broke the monolith, upskilled their own people, and built a future-proof, scalable system that’s setting the standard for UI modernization. Recognition? Governor’s Public Service Achievement Award. National impact? Shaping the Open UI Initiative. This is what real innovation in government tech looks like. 🔥 📖 Read the full story: https://hubs.li/Q036Jg6v0

☕Event sourcing, real-world insights, and an open conversation—over coffee. Join Sara Torrey and Marc Klefter for an interactive discussion on event sourcing—how it works, why it matters, and how it’s shaping modern systems. Bring your questions, challenges, and curiosity. Register below and be part of the conversation. #EventSourcing #Microservices

Distributed Across Space and "Time" In #EventSourcing, the Decider (or Aggregate) is unique in that it both publishes and later consumes the events it produces. However, unlike a traditional distributed system where components are spread across different nodes in space, the Decider is distributed across time. It persists its state as a sequence of immutable events and reconstructs itself by replaying those events when needed (command is handled). This makes it a temporal rather than spatially distributed component—operating as both the originator/publisher and the consumer of its own history.

2025 is the year of Axon Framework 5. Later this year, we'll be rolling out major improvements to make event sourcing even easier. Which feature are you most hyped about? Vote below & tell us more in the comments.

Last week, My Cubes B.V. had the pleasure of hosting Allard Buijze, CTO of AxonIQ, for a hands-on workshop on Axon Server and Axon Framework. His insights reinforced why Axon is a game-changer for scalable, event-sourcing systems and how it can seamlessly enhance workflow automation solutions. As an implementation partner of both AxonIQ and Camunda, we specialize in combining these powerful technologies to build more flexible, resilient, and intelligent business solutions. Curious about how this can transform your business? Let’s talk! 🚀 #AxonIQ #EventDrivenArchitecture #WorkflowAutomation #AxonFramework #AxonServer #MyCubes #Partnership

⚔️ Brave Coding Hero! Have you heard about my Heroes of Domain-Driven Design blog series? 🗺️ In this series, I explore #DomainDrivenDesign practices that have been battle-tested by me in real-world projects, using analogies from the game Heroes of Might & Magic III. This fresh approach helps you understand my commercially-used software development process (featuring #DDD, #EventStorming, #EventModeling, and #EventSourcing) in a fun and engaging way. 👉 Check it out at DDDHeroes.com ☕ Recently, I've prepared source code example for the series in #Java with a #ModularMonolith approach using #AxonFramework from AxonIQ. You can find the code on GitHub, complete with a detailed README: 👉 https://lnkd.in/dF9B6Cpy 🛠️  This project extensively leverages #EventSourcing along with the #VerticalSliceArchitecture. 👇 The package structure (screen below), in the #ScreamingArchitecture style, clearly shows the capabilities of the system by making explicit: commands available to users (+ business rules for them), events that capture what happened, queries for retrieving information, and system automations. 🤔 I used to organize my app into packages like "domain", "application", "infrastructure" and "presentation" at the highest level, but I found using packages per slice from the #EventModeling approach much easier to work with. The code that is related to one another is as close as possible. If I want to change something in a given business feature, I don't have to jump around the entire codebase. #NaKodach #ZycieNaKodach #MateuszNaKodach #HeroesOfDDD #DDDHeroes #HeroesOfDomainDrivenDesign

Looking for help again! Here's my question: When registering, for example, a message handler, what would you expect as a 𝗿𝗲𝘁𝘂𝗿𝗻 value? 1. 𝗡𝗼𝘁𝗵𝗶𝗻𝗴 - I've just registered something, why do I need a response? 2. 𝗖𝗼𝗻𝗳𝗶𝗿𝗺𝗮𝘁𝗶𝗼𝗻 - Some boolean mentioning the registration was successful or unsuccessful. 3. 𝗥𝗲𝗴𝗶𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 𝗰𝗮𝗹𝗹𝗯𝗮𝗰𝗸 - A callback object of the registration that can be used to undo the registration. 4. 𝗧𝗵𝗲 𝗿𝗲𝗴𝗶𝘀𝘁𝗿𝘆 𝗶𝘁𝘀𝗲𝗹𝗳 - The registry you invoked the registration on should be returned for fluent interfacing. 5. 𝗦𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗲𝗹𝘀𝗲 𝗲𝗻𝘁𝗶𝗿𝗲𝗹𝘆 - Fifth, sixth, or seventh options are also possible. Be sure to share in that case! To be a bit more concrete, let's say we have a command handler registry. To this command handler registry, you can (surprise!) subscribe command handlers. Thus, I am wondering what would be best for users of such a registry concerning the return type. So, what would you expect from a CommandHandlerRegistry#subscribe(CommandHandler) method invocation? By the way, Axon Framework currently takes option 3. And, if you are wondering further, yes, we are reworking this side of Axon Framework at the moment; hence the question ;-) Your 2 cents would be much appreciated, as always!