1
votes

In Axon, can I configure a different repository per aggregate type? Some of my aggregates may be event sourced, while it makes no sense for others if there's no need for auditing or restoration to an earlier state.

In the documentation about repositories and event stores, it says to implement the interface Repository<T>, which binds to a specific type of aggregate.

/**
 * The repository provides an abstraction of the storage of aggregates.
 *
 * @param <T> The type of aggregate this repository stores.
 */
public interface Repository<T> extends ScopeAware

Which leads me to believe that I can implement a Repository<Car>, Repository<Garage> and so on which may or may not be event sourcing, annotate them with Spring's @Repository and I'm good to go. Is that the case?

I'm aware that a similar question exists, however the answer just states:

you can only use a single Repository to load an Aggregate.

This doesn't clarify whether a single repository is bound to all aggregates, or to one aggregate type.

Set Validation

As a side question, will using a Standard Repository as opposed to an Event Sourcing Repository alleviate the problem of uniqueness constraint checking in CQRS? When storing the state of an aggregate (in contrast to just events), I could define uniqueness constrains in the underlying persistence storage. Upon commit, the command should fail and no events should be dispatched. Am I correct?

1

1 Answers

3
votes

Your application can very well both have the, what's internally called, GenericeJpaRepository and the EventSourcingRepository along side one another. What you can't do however, is have both repositories for a single Aggregate implementation.

Luckily I see that that's what you're looking for, different ways of storing different aggregates. How to configure this depends on one thing though. If you are in a Spring environment, simply annotating your state-store Aggregate with JPA annotations is sufficient. If you omit these JPA annotations, it will automatically default to being an Event Sourced Aggregate. If you are not using Spring however, you can configure this by using the AggregateConfigurer#jpaMappedConfiguration for state-stored Aggregates and AggregateConfigurer#defaultConfiguration for the Event Sourcing approach.

Simply put though, you very likely do not have to implement your own Repository. Sorry to hear the documentation led you to believe this was the case, I'll ensure we'll adjust that.

In regards to your set validation question, I am not sure to call it 'solving the problem' more as to moving it to the database layer. As the article you share suggests, that is one of the solution to solve the problem, but it comes at a price.