axon | loaded DI | Dependency Injection library

I'm using Axon for implementation of CQRS/Event sourcing in my Vert.X microservice. In the bootstrap of my Verticle I have a createInfra methid for creation of my Axon context. When I try to get a ressource from ny projection I have no result and the request executed without end. When I check the QueryGateway, in the SimpleGatewayBus I have no subscription.

If someone can help me for fix my Axon configuration ? And I have a trouble with MongoDB Eventstore configuration.

Verticle

I have a CQRS/Eventsourcing architecture with 3 microservices. I implemented 2 microservices with vert.x 4 and I implemented CQRS/Eventsourcing without framework to improve my knowledge of this type of architecture. For the third microservice I would like to use AxonIq Framework but I have a problem with Aggregate annotation because it's not avalaible with vert.x but only with Spring. I implemented a Spring microservice using Axon and everything work fine but I would like to know if someone can help me for use vert.x with AxonIq ? If anyone know a workaround for this problem ?

Thank

What's the simplest way to do a basic GET on the Aggregate in a REST-Axon program, without AxonServer?

• I have a simple springboot Axon-and-REST application with an aggregate FooAggregate.
• I create the Foo with a POST /foos which send a command on the command gateway, etc.
• I query the list of all Foos by actually querying GET /foo-summaries, which fires query objects on the query gateway, and returns where FooSummary objects, where FooSummary is a JPA entity I create in a projection that listens to FooCreated and FooUpdated events.

All standard stuff so far. But what about simple GET /foos/{id} ?

That URL /foo/{id} is what I want to return in the Location header from POST /foos And I want this GET to return all of the details of my Foo - all of which are modeled as properties of the FooAggregate (the FooSummary might return a subset for listing)

Now, Axon documentation suggests this:

Standard repositories store the actual state of an Aggregate. Upon each change, the new state will overwrite the old. This makes it possible for the query components of the application to use the same information the command component also uses. This could, depending on the type of application you are creating, be the simplest solution.

But that only applies if I use state-stored aggregates, right? I'm using Event-Sourced aggregates, with a JPA eventstore.

My options would appear to be:

1. Forget about the event-sourcing and use the stored-state aggregate approach, as suggested as being the 'simplest' approach (I don't have any specific need to event source my aggregate - although I am definitely event sourcing my projection(s)

2. Keep the full details in my FooSummary projection table, and direct GET /foo/{id} to there with a slightly different query than GET /foo-summaries (alternative, just call it GET /foos and return summaries)

3. Create a separate "projection" to store the full Foo details. This would be effectively identical to what we would use in the state-stored aggregate, so it seems a little weird.

4. Some 4th option - the reason for this question?

I am using Axon with Spring boot and will like to list an event history for an aggregate. With the event store -> readEvents(String id), we only get events from the last snapshot.

Still new to java and axon, having troubles to setup integration test suite using spring and axon.

Basically, I have some process, which:

• starts with command1
• goes to command handler on aggregate and event1 is dispatched
• event1 is processed by some policy (event listener) and command2 is generated
• command2 is processed by command handler service (thus has no aggregate id) because I need to process something with third party
• event2 is dispatched and processed by another event listener, so command3 is dispatched
• command3 is processed by aggregate and event3 is dispatched

I use axon tests for unit testing aggregates and it works great.

But I would like to add "integration" tests to:

1. check the whole flow, like: when command1 dispatched then event1, event2, event3 is recorded (actually don't care about fields, just to have confidence the whole thing is glued as expected)
2. check the service command handler work as expected in manner "when command2 dispatched, then event2 is recorded"

I was partly succesful with 1) by doing:

So, I'm working on a PoC for a low latency trading engine using axon and Spring Boot framework. Is it possible to achieve latency as low as 10 - 50ms for a single process flow? The process will include validations, orders, and risk management. I have done some initial tests on a simple app to update the order state and execute it and I'm clocking in 300ms+ in latency. Which got me curious as to how much can I optimize with Axon?

Edit:
The latency issue isn't related to Axon. Managed to get it down to ~5ms per process flow using an InMemoryEventStorageEngine and DisruptorCommandBus.

The flow of messages goes like this. NewOrderCommand(published from client) -> OrderCreated(published from aggregate) -> ExecuteOrder(published from saga) -> OrderExecutionRequested -> ConfirmOrderExecution(published from saga) -> OrderExecuted(published from aggregate)

Edit 2: Finally switched over to Axon Server but as expected the average latency went up to ~150ms. Axon Server was installed using Docker. How do I optimize the application using AxonServer to achieve sub-millisecond latencies moving forward? Any pointers are appreciated.

Edit 3: @Steven, based on your suggestions I have managed to bring down the latency to an average of 10ms, this is a good start ! However, is it possible to bring it down even further? As what I am testing now is just a small process out of a series of processes to be done like validations, risk management and position tracking before finally executing the order out. All of which should be done within 5ms or less. Worse case to tolerate is 10ms(These are the updated time budget). Also, do note below in the configs that the new readings are based on an InMemorySagaStore backed by a WeakReferenceCache. Really appreciate the help !

OrderAggregate:

I know Axons messgaes should be located in a same packages. but Should also the exceptions used in other apps be in the same packages?

cuz I'm doing Sagas and compensation transcations and

for example when PaymentService applicatons's PaymentAggregates instance will throw NotEnoughMoneyException(if there is no enough money) and OrderManagermentSaga(orchestration Saga instance) have to receivce Exceptions from PaymentService should the exceptions have to same packes?

I've been talking too much the point is "Should also the exceptions used in other apps be in the same place?"

My question here is quite straight as mentioned in the subject. However, please allow me to give some brief explanation here about my innocent thoughts. I've been using Axon for approximately 10 months now. I used to design my project structure based on the Hexagonal architecture with two top level packages respectively for domain and infrastructure. Furthermore, domain package will contain different domain objects (as explained in the DDD concept) such as follow:

1. Aggregate (this will be an Axon aggregate class).
2. Repository (in my case, this will be a Spring Data Repository interface).
3. Entity (in my case, this contains any lookup entity that i used for set-based consistency validation as written here).
4. Service Port (collection of Input and Ouput port interfaces).
5. Commands (representing Axon Command object).

As for Events, I used to put them on a different module that I compiled as a jar file, so I can share it to other developers whom going to use the same event in their project.

I've noticed recently that all of my commands and events were basically anemic models (an anti pattern that we should avoid). Is there any good practice on this ? Or, Is it something that intentionally used by design ?

I've been thinking to put my Command classes within my Aggregate class (as an inner classes). At least by using this approach I won't end-up with having so many anemic models scattered outside. Any thoughts ?

I'm trying to convert a CompletableFuture> to a Flow. The extension function I'm trying to write is