AxonIQ

Five mistakes that turn a successful event modeling session into a mere "nice try." The past few clients I have facilitated event modeling sessions for each indicated that they had tried it before. They didn't get the results from those sessions that they had expected then, but now they did. So, what makes the difference between their attempts and those we have guided? I'd love to say I made all the difference as a facilitator, but that's not it. When doing event modeling, especially for the first time, there are a few common mistakes to avoid. 1️⃣ Developer-only participants. Convincing the business (or any non-developer colleagues, for that matter) to join an event storming session might require a bit of persuasion. But the session's results rely on their presence. Alberto Brandolini says you need two types of people: those with questions and those with answers. Developers are generally the people with the questions. When we lack people with answers, developers will start making things up that make sense to them. 2️⃣ A(n inexperienced) facilitator wearing too many hats. Facilitating an event modeling session requires an objective view of the process. Distinguishing discussions necessary to reveal missing parts of the model from those that just waste time is a lot easier when you're not partaking in the discussion yourself. As a stakeholder, it's difficult to remain objective. 3️⃣ First-time event modeling sessions always involve a lot of awkwardness. Personally, I love to see how teams go through different stages. Initially, there is hesitation. Is this an event? What are we supposed to do? As time progresses, participants learn what makes up proper events in the system. When the flows start to emerge, the team gains more confidence. At the end of day one, they got the process and realized they'd got more questions answered than they anticipated. 4️⃣ Use of technical terms. A good event modeling session requires both technical and non-technical attendees. People with questions and people with answers, remember? The environment needs to be welcoming for both groups. Language is an important part of that. If developers start talking in technical terms, the non-technical attendees will feel out of place. Avoid terms like Aggregates, Sagas, and Query Models. Aggregates don't need to be discussed anyway. Sagas are Automations or Processes, and green stickies represent Information. 5️⃣ Focusing on the current system's behavior instead of the desired state. In many cases, a system has already been implemented. If your modeling session is about what a new version of a system should do, then don't get distracted by what the current system does. Or worse, how it does it internally. Be clear about the scope at the start of the session. With these 5 points avoided, I am confident you'll have a successful event modeling session. When in doubt, ask an experienced external facilitator to help you get started. You won't regret it.

I have just released Axon Framework and Axon's Bill of Materials. Versions 4.10.3 and 4.10.4 respectively. As a patch release, Axon Framework received some minor fixes. One of these is a configuration mishap for aggregates. An issue that specifically acted up when using the creation policy annotation in combination with a polymorphic aggregate. Thanks again to Dillon Providen for validating there was something amiss in this area. And, more importantly, for being patient for his issue to be released. Next to that, we introduced a cleaner retry behavior into the Framework's persistent stream feature. This will ensure that, in the case of event handling failures, we enter an exponential back-off period. Furthermore, for the Bill of Materials, the following dependencies have been updated: • Axon Framework to 4.10.3 • Multitenancy extension to 4.10.3 • Spring AoT extension to 4.10.1 The Multitenancy extension received a single fix between 4.10.2 and 4.10.3. Some of the multitenancy-specific infrastructure components were missing the "span factories." These span factories support OpenTelemetry and AxonIQ Console tracing, so they are rather important. Luckily, adding these was extremely straightforward. For the Spring AoT extension, we were nudged by Lukas V. (@xvotro02 on GitHub), who shared that there were two runtime issues. First, the aggregate member annotation, with a specific forwarding mode, would throw an exception. Second, an annotated command handler interceptor would similarly throw an exception. Both were quickly solved by expanding the hints given to Spring during compilation. So, thanks to Lukas .V for sharing these issues with us! If you are curious about the full release notes, can you read those here - https://lnkd.in/e3Vrxdhk That's all! I want to thank everybody who will check out these releases. And if you find any issues with any, be sure to reach out!

Struggling with aggregate boundaries? Say goodbye to rigid rules. See how we're making event sourcing easier below. #EventSourcing #SoftwareArchitecture

Event Sourcing "Friday FUD": One challenge of Event Sourcing is that I can't change historical data. Or can I? The short story is simple: you can. But you might get in trouble, and it's not because of Event Sourcing. One of the things I love most about event sourcing is that it forces people (not only developers) to think in terms of messages—little nuggets of information that flow between components in a system. Some of these nuggets describe something from the past and hence are stored for longer. To make these information streams reliable, we use them directly to drive decisions in our system. The main point here is these nuggets of information that flow between components in a system. Whether we use Event Sourcing or not, once information is shared between systems, we should be extremely cautious when changing it. There is an assumption that because Event Stores are append-only storages, it's impossible to change their contents in other ways than appending more data. While that might be true for some specific implementations, it's not a general rule. At AxonIQ, the event store is part of Axon Server. We have a feature to transform the stream of events. 🤔 So I can change the data in historical events! That's great. Update queries for the win! Well, no. Coming back to the nuggets of information flowing between components, you shouldn't. If you change something in the past, the other systems won't be notified of this change. As a result, you have eventually reached a state of inconsistency. 🤔 If change is bad, why have a feature to change historic events? Not all changes are equal. As long as a change doesn't modify an event's semantics—its meaning—it is no problem to change it. We're only changing the representation of the same "nugget of information." These changes can happen for several reasons. Schemas may evolve, requiring you to change the representation of certain messages. Privacy regulation may also require removing information stored in your historical events. While there are different strategies to deal with these changes, altering the data should not be discarded as an option simply because event sourcing is advertised as append-only. But make sure to look at alternative solutions as well. Event Sourcing comes with many ways to address these issues. 🤔 But what if we need to change an event's semantic meaning? Don't. Changing that will change the story you've already shared with other systems or components. This is where Event Sourcing's strength comes in: fix forward. Make corrections by appending new events. These will then travel around your system like any others, fixing the "story" in downstream components as well. And yes, the fact that it happened will remain visible in the event store. So be it... Interestingly, the inability to change data is attributed to Event Sourcing, while it's actually Event Sourcing that provides better ways to deal with the situations that require it.

Event Sourcing "Friday FUD": One challenge of Event Sourcing is that I can't change historical data. Or can I? The short story is simple: you can. But you might get in trouble, and it's not because of Event Sourcing. One of the things I love most about event sourcing is that it forces people (not only developers) to think in terms of messages—little nuggets of information that flow between components in a system. Some of these nuggets describe something from the past and hence are stored for longer. To make these information streams reliable, we use them directly to drive decisions in our system. The main point here is these nuggets of information that flow between components in a system. Whether we use Event Sourcing or not, once information is shared between systems, we should be extremely cautious when changing it. There is an assumption that because Event Stores are append-only storages, it's impossible to change their contents in other ways than appending more data. While that might be true for some specific implementations, it's not a general rule. At AxonIQ, the event store is part of Axon Server. We have a feature to transform the stream of events. 🤔 So I can change the data in historical events! That's great. Update queries for the win! Well, no. Coming back to the nuggets of information flowing between components, you shouldn't. If you change something in the past, the other systems won't be notified of this change. As a result, you have eventually reached a state of inconsistency. 🤔 If change is bad, why have a feature to change historic events? Not all changes are equal. As long as a change doesn't modify an event's semantics—its meaning—it is no problem to change it. We're only changing the representation of the same "nugget of information." These changes can happen for several reasons. Schemas may evolve, requiring you to change the representation of certain messages. Privacy regulation may also require removing information stored in your historical events. While there are different strategies to deal with these changes, altering the data should not be discarded as an option simply because event sourcing is advertised as append-only. But make sure to look at alternative solutions as well. Event Sourcing comes with many ways to address these issues. 🤔 But what if we need to change an event's semantic meaning? Don't. Changing that will change the story you've already shared with other systems or components. This is where Event Sourcing's strength comes in: fix forward. Make corrections by appending new events. These will then travel around your system like any others, fixing the "story" in downstream components as well. And yes, the fact that it happened will remain visible in the event store. So be it... Interestingly, the inability to change data is attributed to Event Sourcing, while it's actually Event Sourcing that provides better ways to deal with the situations that require it.

Your system’s past holds the key to its future. Event sourcing can transform your architecture, fueling everything from auditable banking apps to machine learning pipelines. But let’s be real: adopting it can feel impossible. That’s where AxonIQ steps in, cutting through the noise and making event sourcing intuitive, scalable, and, dare we say, easy. Curious? We break it all down below. 👇 Have you tackled event sourcing in your projects? Share your story in the comments—what worked, what didn’t, and how do you see the future of event-driven systems? #EventSourcing #Microservices #SoftwareArchitecture

I am not head over heels for AI. Nonetheless, something quite interesting from that space was brought to my attention last week, and I would like your input on it. Axon Framework sees new issues and pull requests weekly. Nothing new there. What is exceptional, however, is that we got a pull request that added a single line. To the "Getting Started" section of the README of all things. To be more specific, the following was provided: You can Ask Axon Guru (https://lnkd.in/ebeRB5Fr), it is an Axon-focused AI to answer your questions. So, an "Axon Guru." An AI that is trained on the Axon Framework GitHub repository and AxonIQ's documentation, to be exact. As I told you, I am not a massive fan of the whole AI thing. There is nothing wrong with liking it; it is just not my thing. Or my thing yet, who knows? But I take any documentation or code provided to Axon Framework seriously, even if my first reaction is full of doubt. So, I checked out this Axon Guru to see what answers it came up with. To be entirely honest with you...the answers are pretty good! Here are some queries I tried: 1. Can I break apart my aggregate? 2. How do I use event sourcing? 3. What should my aggregate identifier look like? 4. Are there test fixtures for Event Handling Components? 5. Can I serialize my messages to protobuf? The only prompt in which I saw it make an error was the Event Handling Components testing. We don't have test fixtures for those. Other than that, the information was pretty impressive! I can honestly imagine there would be quite a few Axon users who would be very happy with a "guru" like this. Nonetheless, I would much appreciate your opinion on the matter: What do you think about AIs like this to help you learn an (open-source) tool or framework? Let me know! Before closing, I would like to thank Kursat A. for taking the effort to (1) set all this up and (2) nudging us with a PR that it exists. Kudos!

Software architecture isn’t just code—it’s about strategy and decisions. What skill do you think sets the best software architects apart? Explore resources for better system design with the all new AxonIQ docs page here: https://lnkd.in/gpVymT3F

🔔 Event Sourcing: Your Boost for NIS2, DORA & AI! Do you want data that stands out? 🌟 The EU is demanding more security, traceability, and transparency with NIS2 and DORA. But hey – why just meet the requirements when you can also make your data AI-ready? 👉 The Magic Formula: Event Sourcing. Unlike "old" systems that overwrite data, Event Sourcing stores every change as an Event. This brings: ✅ Maximum Traceability: Who changed what, and when? ✅ Perfect Compliance: NIS2 and DORA requirements? Check. ✅ AI-ready: Data that AI will love. 💡 Our Gamechanger: The Axon Framework! For over 8 years, we’ve relied on AxonIQ’s framework – because it just works and is fun to use. And this year, we were even sponsors at the AxonIQ Conference in Amsterdam. What did we bring back? Insider tips, best practices, and exciting success stories! 🚀 So, what are you waiting for? Event Sourcing is the key to starting the future securely, efficiently, and AI-ready. 📩 Let’s talk! Send us a message here or schedule a meeting directly. We’ll show you how Event Sourcing can transform your business. #EventSourcing #softwareengineering #Innovation