Returning data from Aggregate method call

Imported from Google Groups
#1

Typically have shyed away from command calls returning data besides just throwing exceptions for domain violations.

Saw that in axon-trader example the authentication query about doing a valid auth is done within aggregate root ?

public boolean authenticate(char[] password) {

boolean success = this.passwordHash.equals(hashOf(password));

if (success) {

apply(new UserAuthenticatedEvent());

}

return success;

}

Best practice question? We have tried hard to not let the domain aggregate return anything and always gone to querydb for answers on readonly questions/logic which does not require any updates.

Whats the rationale for best practice as agreggates returning data can open up other possibilities of querying aggregate where we do not need to store query db data especially for domain decesioning logic type queries like the one above which can be very cumbersome for the query db?

Any thoughts?

Cheers…

#2

Hi,

preventing return values is a good practice. But sometimes, preventing it will make an application more complex. In the end, the goal is to reduce complexity.
Be careful with “[we] have shyed away from command calls returning data besides just throwing exceptions for domain violations”. Exceptions can also be considered return values. So a “void” method is not a guarantee of a method without return value.

In the case of authentication, there are a few things to note.
First of all, you want to block a user from accessing the application until the authentication is executed completely. Secondly, in many applications, application access is one of the most important things to audit. An the third is that many applications will add business logic to authentication, such as blocking a user when he did 3 failed attempts within 5 minutes.

So, depending on the type of application and the importance of auditing authentication attempts, you can decide to handle this as a command or -if all of the above do not apply- as a Query. Waiting for a result of a command being executed is not really a bad thing, especially if the alternatives introduce a lot more complexity…

But would I call this a best practice? The best practice is to do what you seem to be the best fit for your specific use-case.

Cheers,

Allard

#3

I think this is very powerful for scenarious discussed where a answer/return can be provided based on domain state and additional logic.. And agree on complexity reduction and redundant code. Also this way segmentation can be done more effectively on query side to query without this type of complexity and spreading of domain logic about aggregate state.

Not sure how cqrs forum would react. I may pose this same question there for a pulse check there and see reaction of opinions.

Cheers..