Is Using Command Interceptors to Maintain Relationships Between Aggregates an Anti-Pattern?

[Steven_van_Beelen]

@ajisrael

Knowing this, do you still think it makes sense to have the LoyaltyBank as an aggregate member on the Account?

Although it is always tough to give a 100% certainty on things, what I do think is important to note is that it is fine for a LoyaltyBank entity to exist in several places. It would just serve a different purpose.

When thinking about CQRS, the “duplication” becomes more apparent, as one entity is in charge of validation (the command model) while the other is in charge of answering questions (the query model). This point does not stop there, though, in my opinion.

You can very well have several command models with their own idea of an entity.

So, concluding: yes, I think there isn’t anything inherently wrong with making a LoyaltyBank aggregate member on the Account.

@ajisrael

In general, I really like how the interceptors and command projections work together to “guard” the aggregates from processing an invalid command, my main concern is if there are any negative performance implications or things that I should be looking out for as the project scales, or if I introduce multiple instances of the command API?

Any interceptor you add has some impact on the system, that’s for sure. It simply blocks the thread from entering the aggregate.

As such, it is paramount to make the interceptor as efficient as possible. However, I would also avoid too much premature optimization in this area, @ajisrael. Just monitor the command handling process in general, and as soon as you see it surpass a team/company-defined boundary, then go for the optimization.

Although this is a shameless plug, we have built AxonIQ Console with just these kinds of monitoring tools in place. If you are not able or allowed to use AxonIQ Console, you can also include other measurements. Our documentation states some approaches you can take, so perhaps that’s helpful for you when the time comes: Monitoring

@ajisrael

Does it make sense to persist those projections into the same database as my event store, or should I try and use something that is known to be a little faster like a Redis Cache maybe?

Redis Cache for the uniqueness constraint would be a smart move to make I think! But, again, I would start optimizing as soon as it becomes a bottleneck, personally.

@ajisrael

If you or anyone else has any additional insights, that would be greatly appreciated. I must say, working with Axon Framework has been one of, if not the, most enjoyable experiences I’ve had in developing software thus far.

Thank you again for your reply @Steven_van_Beelen, and for all your contributions to this amazing community.

Thanks for these kind words, @ajisrael! I can assure you, I will keep helping out in this area, so be sure to see responses from my in the future!