CODEWITHSUNDEEP
javaevent-sourcingaxon
dariuz
dariuz

Reputation: 21

Where to put event upcasters in a microservice architecture?

I'm "playing" with Axon Framework with some small examples where the query and command services (and the logic behind them) are running as separated applications in several Docker containers.

Everything works fine so far and I started to evolve the event versioning topic. I haven't implemented that yet, but I like the idea to share the events as an API via JSON schema. But I've got stuck using that idea with the potential need of event upcasters.

If I understand that approach correctly every listening component has to upcasts the events independently, therefore it might be a good idea to share the upcasters, there is no need for different implementations, right? But then the upcasters seem to became a part of the API, or am I missing something? How do you deal with that situation? Or generally, what are the best practices for API definitions in such scenario?

Upvotes: 2

Views: 201

Answers (1)

Steven
Steven

Reputation: 7275

When accessing a microservices environment with distinct repositories for the different services, I feel it is common place to have a dedicated module/package/repository for the API of the given microservice. Or, a dedicated module for the shared language within a Bounded Context.

Especially when following the notion of Bounded Context, thus that every service within the context speaks the same language, to me emphasizes the requirement to share the created upcasters as well. So shortly yes, I would group upcasters together with the API in question.

Schema languages typically also have solutions in place to support several versions of a message for example. Thus if you would be to use a schema language as your core API, that would also include a (although different) form of upcaster.

This is my 2 cents on the situation; hope this helps you out!

Upvotes: 1

Related Questions