Preparing monolith for Axon

Imported from Google Groups
1

Greetings,
I have 2 apps. 1 is very simple (voice notifications) and uses Axon. The other is the monolith I want to decompose. Basically, the goal is to introduce Axon to the monolith based on the webinar, and make it work with the notifications app. I just need a little direction regardless of whether or not the suggestions make sense for my situation. Feel free to provide answers based on assumptions as long I know what those assumptions are.

The new apps will belong to a different namespace (ie. everything in the monolith is under com.foo.app but the new names will be com.bar.). Per the webinar, I will find interesting pieces of code from which to publish events. Ideally, will the events belong to the new com.bar namespace?

Before putting such code in place, should I publish/generate, say, Created events for the pre-existing data? I mean, it doesn’t seem to make sense that I would publish a SpecificationApproved event before a SpecificationCreated event

The simple app already has an event store. Ideally, will the monolith use that same event store? Assuming they would, does anyone have any advice for configuring the event store to use a non-@Primary datasource/EntityManager/etc… (see diagram) with Spring Boot? Documentation/examples are provided for setting up 2 of everything and marking 1 as @Primary, but what about the Axon piece?

Thanks in advance!

diagram.PNG

2

Hi Brian,

I hope I can answer your questions thoroughly enough. If you think anything from my response is missing or is not completely what you were requesting, feel free to post further questions.

The first question I spot is whether you should use the same name space for the events you’re going to publish in your new application.
I’d personally say yes, since from you description it seems that those events will be specific for you new application.

As the new application has the ‘com.bar.xxx’ namespace, those events should also belong to the ‘com.bar.xxx’.

The namespace of an event will be part of the payload type of an event message being stored in the event store.
So for example, a SpecificationCreatedEvent its payload type would be ‘com.bar.xxx.SpecificationCreatedEvent’, which will be stored in the payloadType column.

Aside this though, you can quite easily adjust the name space and thus the payload type of your events latter on, so it should not be that big a deal if you find out that you want to update the name space.
When you’d de-/serialize your events when using XML, you can simply add an alias for the adjusted payload type. If using Jackson, you can write a simple upcaster which adjusts the payload type for you.

For you second question, it depends on what the requirements are in your situation.
If it’s okay that you do not have events for lets say Specification which have been created in the past, then that’s fine.
If you however have the requirement that any command model / aggregate created in your old monolith should have a corresponding set of events, then you should most definitely write some form of migration tool which instantiates all the aggregates (and thus their events) based on existing data in your monolith.

Thirdly, I’d suggest no to use the same event store for two different applications.

You would be mixing concerns between two (probably) completely different Axon application to much if you would use the same event store.
As you might have read or know already, TrackingEventProcessors pull events from the Event Store.
In a mixed EventStore situation, those processors would thus possibly pull dozens of events it does not care for at all, as those are part of a different Axon context.

I hope this gives you some insights Brian, and feel free to come with any additional question you might have!

Cheers,

Steven

3

Hello Steven,
Thanks for the feedback. In regard to #3, had that task not been given to me, that functionality would have ended up in the monolith. It was a feature of a different application and rather than add it to the monolith, I thought it would be a good opportunity to get my feet wet with Axon. Does that change anything? Better yet, to get a little more specific, let’s say that within the monolith, we have 3 areas of interest: Specifications, Companies, and Users. If those are broken out into separate components/apps, then does that mean I might want to consider having separate event stores for each?

4

Hi Brian,

I’d let that depend on the Bounded Context you’ve got in mind.

Guessing as the functionality was contained in one application (the monolith) in the first place, that probably your ‘Specifications’, ‘Users’ and ‘Companies’ do belong to the same Bounded Context.

If that’s the case, I would add events from those three, may I guess aggregates(?), do belong in the same Event Store.

If they are in the some context however is something I cannot say with a 100% confidence, as I’m not versed in the Domain you’re working in.

Does that give you the insight you need Brian?

If not, I’d be glad to help you further with this.

Cheers,

Steven

5

Hello Steven,
I’m rather familiar with the app and it seems like I’m dealing with one BC based on the definition, but I need to do some further analysis to make that final determination. For the sake of argument, I think we can go ahead and assume that there is only 1 BC between the 2 apps. Currently, the monolith sends out email notifications only. The app I developed only handles voice notifications (ie. makes a phone call to an intended recipient) ATM, but I plan on moving the email stuff into it as well. I would say that the 3 things I mentioned are indeed aggregates. Your feedback is definitely helpful and appreciated. I’m relatively new to Axon/CQRS/ES, etc… so I’m just trying to figure out how to attack this problem the right way.

6

Hi Brian,

I think your assumptions here (for the time being) are correct, so from that perspective I’d again confirm that one Event Store sounds sufficient in your scenario.

And I’m glad I could help you out with this Brian!
I always find it a pleasure to help out when somebodies new to CQRS, ES, DDD and of course Axon Framework specifically.

If you have any follow up questions in this space which you cant seem to find the answer for, feel free to drop another post.

Cheers,

Steven

7

Hello Steven,
Now that that’s out of the way, how might I go about getting things setup? Does the event store go into a separate database? Do both processes connect directly to it? Am I going to need something like RabbitMQ so that the 2 processes can communicate? I will figure out the details, but I’m interested in knowing what an ideal setup would look like for this. If there’s a webinar that I should watch (aside from the “big ball of mud”), then I will gladly do so. If at all possible, I think it would be helpful if there was a webinar that takes a sample monolith and goes thru the steps of actually breaking it out into separate components. I don’t imagine something like that will happen overnight, but perhaps it could be added to some sort of “wish list”.

Thanks!

8

Hi Brian,

We typically suggest to create your application ‘monolith first’, but whilst doing so keep in mind to clearly separate your code in sensible packages/modules which later on might become separate services.
Were you’ll move from there is a big ‘it depends’, meaning that it depends on the needs of your application.
There is a conference talk Allard gives, which he dubbed “A Pragmatic Approach to Microservices with Axon Framework”, which gives you a view of how your third question (RabbitMQ yes/no) could be solved.
Your other two question (1. separate database for EventStore and 2. do both process directly connect with it) are, again, dependent on what you applications requirements are.
Taking the ‘monolith first’ and sensible package/module suggestion though, I’d general put (1) the EventStore in it’s own database (a part from the query side/database of your application) and (2) I’d directly connect them to the store to keep it simple.

Added, the AxonIQ channel might contain some valuable info.
I do however not have a clear cut webinar for you, as (again) ‘it depends’.

Hope this gives you some insights Brian!

Cheers,
Steven