Integrating Axon into exsiting application

Imported from Google Groups
#1

Hi

I’m having a big dilema about integrating axon into our existing web application. We want to build Axon based backend, so my question is
how is possible to migrate or populate an event store with exact same event stream sequence, so for example if i’m about to modify an user
previously created from our frontend, Axon can load that same aggregate from event store and then apply the changes.

Thanks

Cheers

#2

Hi Nedo,

I am not sure if I understand the problem correctly. Do you want to convert existing, flat data into event sourced data? Or does the existing application already have some sort of history?
I’ll just assume the first scenario, since that is most common.

There are two approaches: you can either create an “MyAggregateImportedEvent” that contains the aggregate state as left by the “old” application, or use a series of events (e.g. “MyAggregateCreated”, “MyAggregateDidSomeThingEvent”, “SomeOtherActivityEvent”, etc…) that will ultimately build up the same state as you currently have.

To insert that state you will need to create a little tool that crawls the old domain model and either inserts events directly into your event store, or send commands to the application to have it generate the events that way. I’ve done that latter on quite a large dataset with a legacy application, and all turned out pretty well. Obviously, any history caused by the import is not really a good reflection on what happened. But mostly, you don’t care at that point.

Cheers,

Allard

#3

Hi Allard

I would prefer the second approach… where events can be created crawlig the old domain model.

Thank you :slight_smile:

#4

There is one caveat I want to warn you for. Yes, we’ve stepped on this trap and had to pay for it :wink:

When backdating events for import, make sure you backdate all events properly. We made some mistakes here and ended up with a “UserCreatedEvent” on let’s say August 3rd, and a “UserLoggedInEvent” on August 1st. When you start replying past events, you will receive them in an awkward order. So either assume “now” for all events, or make sure that the backdating is properly done on all events.

Cheers,

Allard

#5

Good to know that… Thanks

Cheers :wink:

#6

Allard, one last question.

The most of our database tables have id column as INTEGER AUTOINCREMENT data type. We would like not to change that structure, but on the other hand, Axon should store their aggregates having id as integer value too.

Can you recommend any solution, except changing the ID datatype to UUID in our tables?

Thanks…

#7

Hi,

we had exactly the same challenge. In general, my experience is that using client generated ids is better. Obviously, there will always be exceptions.

What we ended up doing for our tool was to keep a table (as a property file) that mapped each old ID (numeric autogen by DB) to the new one (random UUID). The tool would populate that file automatically as it worked its way through the tables. So each time a reference to another entity was found, the mapping would provide the new identifier.

Cheers,

Allard