What about default configuration for eventBus, commandBus and repositories

Imported from Google Groups
1

Hi,

I was reading the nice tutorial at http://blog.jteam.nl/2010/11/12/tutorial-getting-started-with-cqrs-and-axon-framework/ and stumbled upon the following configuration lines:

axon:annotation-config/

<axon:event-sourcing-repository id=“orderRepository” aggregate-type=“com.acme.oms.commandhandling.Order”/>
<axon:jpa-event-store id=“eventStore”/>

<axon:event-bus id=“eventBus”/>

<axon:command-bus id=“commandBus”>
…
</axon:command-bus>

I was thinking what would happen if you’ve got 10 Aggregate Roots (AR’s). That would mean that the line:
<axon:event-sourcing-repository id=“orderRepository” aggregate-type=“com.acme.oms.commandhandling.Order”/>
will be duplicated 10 times.

It would be nice to use convention over configuration. The above, except for the commandbus, could be done with an tag like:

<axon:annotation-config event-store=“jpa” repository=“event-sourcing” />

You could use the component-scan to find all AR’s and create a repository for them based on the name of the AR and the suffix Repository.

And if you want to do something non default you can always create the needed beans yourself. For example the commandBus with a SpringTransactionalInterceptor

Is this possible and would it be a nice feature?

Martin

2

Martin,

technically, it should definitely be possible. If Spring can do component scanning, so can I ;-). It’s definitely something that I will be looking into, but for now, I don’t consider it the highest priority.

Thanks for the idea.

Cheers,

Allard

3

Have any improvements been done wrt convention over configuration, I get a bad feeling being required to duplicate all that repository wiring.

4

Hi,

no work has been done in this area yet. The issue is that the “convention” may not be as conventional as it may appear at first glance. While event sourcing may seem to be standard, it should absolutely not be treated as such. As any component, event sourcing should be backed by a business case. Some aggregates may be event sourced, while others are OR-mapped. That’s why I am not really sure a convention here is the right approach. It may simply lead developers into false assumptions.

And, of course, there were other priorities that made me do other stuff than this.

Cheers,

Allard

5

I understand that event sourcing should not be considered the only way to do things in Axon as the ORM approach is just as sensible given proper context. However, do you agree that if one has 15-20 ARs that all use event sourcing, this becomes tedious and ceremonial:

<axon:event-sourcing-repository
id=“repo”
aggregate-type=“my.domain.aggregateroot”
event-bus=“eventBus”
event-store=“eventStore”>
</axon:event-sourcing-repository>

Optimally, with respect to event sourcing then generics and constraints could help a bit killing all that ceremony. Something similar to

public interface Repo
{
T Load(object id, long version) where T: es-ar-base-class-or-interface
void Save(…) where …
}

Let’s say that event sourcing is being backed by a business case or just deliberate choice to avoid ORM ceremony, then what are the differences in repositories across ES ARs?

“It may simply lead developers into false assumptions.”

Not if it is added to the otherwise excellent and thorough documentation :slight_smile: