Alright, I took a second look which give me some subsequent question and remarks.
Firstly, are you planning to do CQRS?
If so, I’d want to suggest to not return the “AggreateObject” as a query result.
The Aggregate should be regarded as your Command Model, whilst returning it as a query result means it’s also the Query Model.
That is completely reverse of what CQRS (Command-Query Responsibility Segregation) suggests.
Secondly, you’ve named a component
I’d want to point out that Commands, Events and Queries are different types of messages.
Thus, a Query-Command is a none existent thing, conceptually speaking.
FetchCommand you are using to retrieve the AggregateObject is named incorrectly.
It should be called something along the lines of
RetrieveAggregateObjectQuery, if you want to use the Aggregate as your Query Model that is (as discussed in my first point).
Thirdly, and lastly, the DisruptorCommandBus is used to split the command handling process from the event handling process of an Aggregate.
In this process, it assumes you are taken an Event Sourcing approach to your Aggregate.
If you want to use your Aggregate as the Query Model too, it is suggested to take a State-Stored approach for the Aggregate, as the entire state of the Aggregate is apparently valuable for query results.
That said, your code snippets suggest you want to return the Aggregate as your Query Model, thus opting against Event Sourcing and thus also opting against usage of the DisruptorCommandBus.
Hope the suggestions point you in the right direction Manoj.