Hi all,
In Axon you can you can attach interceptors to command bus. Since
interceptors are executed before command handler I think we can put
aggregate validation code in them, so if validation fails it won't
reach the command handler instead the exception can be propagated back
to caller, but I also doubt if this is a good idea since they're not
meant to be aggregate specific.
Any advice would be greatly appreciated.
Thanks & Regards,
Setya
Hi Setya,
there are two forms of validation, that need to be treated differently: structural validation and rules validation.
Structural validation is about verifying that all necessary data is available and has the right format. This type of validation can easily be done using JSR 303 annotations, for example, and an interceptor on the command bus. Failure in this type of validation is typically an indication of a bug in the client code. After all, the client should never be able send structurally incomplete commands.
Rules validation is about checking that the command makes sense given the current state of an aggregate. This type of validation is not suitable for interceptors and should be done inside the aggregates. After all, they are the only ones that know their state.
Hope this helps.
Cheers,
Allard
Allard,
Thank you for your response.
Glad to know that structural validation fits into the interceptors.
I have another question regarding validation, but I'll put them in
different topic next.
Thanks & Regards,
Setya
Allard Buijze wrote:
Hi Setya,
An example for JSR303 annotations in a command mentioned by Allard can
be found here:
http://code.google.com/p/axon-auction-example/source/browse/trunk/auction-command-api/src-gen/main/java/org/fuin/auction/command/api/base/RegisterUserCommand.java?r=195
Checks inside the aggregate you can find here:
http://code.google.com/p/axon-auction-example/source/browse/trunk/auction-command-server/src/main/java/org/fuin/auction/command/server/domain/User.java?r=195
(See "verifyEmail(..)" for example)
Cheers,
Michael
Hi Allard,
When checking for duplication, where should we put the code ?
Regards,
Setya
There are several ways to do a duplication check. In this case, I assume that “username” should be unique across several aggregates.
It should always be done client-side, by doing a query for “existing” usernames.
On the server side, you can take some additional steps:
One is to create a collection that uses a lock (could be a table with only usernames, and a unique constraint for example). When executing a command, first, you append the username to that table. If that succeeds, you continue. This provides the best safety, but comes at a price: you can only have a single table with these usernames for all your machines. Or apply a smart routing process (A-M stored on instance1, N-Z stored on instance2).
Another way to do it is inside the query model. When it detects that it cannot create a new user because of a duplicate, it can raise an event “DuplicateUserNameDetectedEvent”. A command handler could then decide to block an account, send the user an apology email, notify an administrator, etc.
The most important thing to keep realizing in this case is: what is the chance of this happening, and what is the damage when it happens. If the username is an email address, chance of duplication is virtually none. In that case, use the second server-side approach. If the damage is significant, the first might be a better option.
Greg wrote a nice blog article about this: http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/
Cheers,
Allard
There are several ways to do a duplication check. In this case, I assume that “username” should be unique across several aggregates.
It should always be done client-side, by doing a query for “existing” usernames.
Does client side mean that we need to use command handler or within command as it is getting populated checking or even before the command gets populated by external client.which seems like more knowledge to the client about domain then needed
It means that the user interface logic should always do a duplicate check before sending out the command. So, a client does a query for “is username abc available?”. If ‘yes’, then send the command. In a regular webapp, it’s probably a piece of server-side logic that does this job.
The only “knowledge” the domain has, is that a username must be unique. That isn’t weird, because you resource bundles probably have messages related to this anyway.
If you use a command handler to return an error on duplicates, it is harder for you UI to translate these exceptions to user-friendly messages on screen. That’s why “pre-validation” is a lot easier to do. You can raise UI-specific errors in that case.
below in the jsr303 validations
public RegisterUserCommand(final String userName, final String password, final String email) {
super();
this.userName = userName;
this.password = password;
this.email = email;
Contract.requireValid(this);
}
The above generates a generic string concatenated exception with multiple errors concatenated with the contraintvaiolationexception on the Contract. What if we want to validate using jsr (I know that the command needs to be pre-validated), however if you are creating a webservice or api and want all the server side containment to a thin non-intelligent client, can the stuctural validation be handled as step 1 before moving the command forward? If the command is not returning a hash of results for these types of errors with their app messages (maybe even locale-aware), then there could be a lot of app intelligence on the thin client. Ideally a quick structural validation similar to the one in address-book with spring-mvc Entity validation binding from ContactsController.java
public String formNewAddressSubmit(@ModelAttribute(“address”) @Valid AddressEntry address, BindingResult bindingResult) {
if (!bindingResult.hasErrors()) {
RegisterAddressCommand command = new RegisterAddressCommand();
command.setAddressType(address.getAddressType());
command.setCity(address.getCity());
command.setContactId(address.getIdentifier());
command.setStreetAndNumber(address.getStreetAndNumber());
command.setZipCode(address.getZipCode());
commandBus.dispatch(command);
…
This above uses a interesting way with hibernate validator to validate an incoming request server side with the query model of the Entity before moving the command forward, however in client controller code leveraging spring-mvc for the binding of the errors to the client.
So how do we get the same objective if without duplication of structural validation logic? assuming a webservice client or a rest api client, which is completely dumb.
Maybe the addressbook example serializing the AddressEntry Entity object to the command and the validation happening there with an exception which populates the errors?
Any ideas??
Thanks
return “redirect:/contacts/” + address.getIdentifier();
}
Another way to clarify this is how to provide facility for pre-validation to client with the api for the app?
Cheers…
First of all, I’d like to say that this issue is not different than if you were using any other architecture for your application. This problem is not CQRS related at all.
Every application has a contract. A client, whatever it is, must stick to that contract. If you start putting UI specific code in the application’s core (for example, providing locale specific explanations in exceptions), what will you do if you have to add a web service to your application? There is always some “shared knowledge” between the UI components and the application (i.e. the contract). If a UI is too dumb to pre-validate whatever it sends out and stick to the contract, it will get an exception. If you use something like 303 validation, there isn’t any code duplication, since both ends of he line can use the exact same contract to validate the command.
You mentioned “assuming a webservice client or a rest api client, which is completely dumb”. How is a web service completely dumb? They will also have to stick to a certain contract… If that contract isn’t coded somewhere, it should be at least documented. Application integration isn’t something you hack together to “see what happens”. A client should always know what to send, and what it expects the application on the other side to do.
Cheers,
Allard
Thanks…maybe I was not clear…the webservice cannot be dumb but the commad API could potentially become a web service/Rest API interface. Having said that how to give helper infrastructure to pre-validate to the client of a webservice/Rest API to (another application, web gui, iphone guie etc) is the challenge and understand not a cqrs issue, however checking to see any best practice to solve that challenge with the command API infrastructure.
Cheers…
Hi,
The way I see it, is that the command infrastructure isn’t really suitable (at least, not meant) for use as an external API directly. Of course, that doesn’t mean that you can’t. I’ve done several integration projects, and lately also with CQRS (and Axon in specific). The commands of your application don’t always have the correct granularity for use with external clients. In Web Services, you might want to allow clients to send requests that map to more than one command in your application.
I always create a separate module that talks to the core API module (which contains the commands, events and shared model object). That module exposes its own API (in its own language, WSDL, for example) to the outside world. That will allow you to refactor the commands without immediately influencing your external API’s.
Cheers,
Allard
Ok got it…makes sense to layer…however the more I think here is a scenario for a valid infrastructure need which could help with a ubiquitous problem for every app.
Any interface for set of ConstraintViolationExceptions which is throwable by a void command and can contain the necessary pre-validation type violation outcome.
For example a java client could benefit from a client side library for prepping the command before sending it to the bus. Conversely if not a java client the command handler can do that check and do a server sider pre-validate before moving the command forward and send a list of these validation exceptions…just a thought…This way all custom constraint violations setup and design can be behind the api and keep the client out of that logic. it seems like this type of infrastructure is a pain with all the manual plumbing needed for every command preperation and repetetive logic. JSR303 api could be leveraged for the same. Think this may be something which does generate a lot of boiler plate repertetive code on client and server again and again…just a thought.
The auction example attempts to do some of this with objects4j library to solve the problem however with a single exception concatenating all the JSR303 violations in a single string, which could be parsed at the client requiring some work. Some plugability/extensibility of this for the infrastructure could be quite valuable for new development of projects leveraging this framework and a very repetetive use case reducing a lot of boilerplate code for the checks and violations of the incoming commands.
example JSR api below…just a thought…thanks for your thoughts on the subject…Cheers
Hi there,
You can use any JSR 303 annotations in your application.
The ones used in the auction example app are just an example how you
can do it - Of course it's up to you what you want to put in your
command.
(To be honest I'm not event sure if the annotations will stay that way
or will change to whatever form... The way is the goal for the auction
example project.)
In general I don't see what exactly the problem with the annotations
is - If you validate the command at the client side you will get -of
course- a list of errors. If you send such an invalid command to the
server I think it's pretty ok to answer with an "Invalid Command
Result" - I don't think there is a need for a list of errors if such a
command hits the server.
Chers,
Michael
The "RegisterUserCommand" (http://code.google.com/p/axon-auction-
example/source/browse/trunk/auction-command-api/src-gen/main/java/org/
fuin/auction/command/api/base/RegisterUserCommand.java) has for
example the following JSR303 annotations:
@EmailAddressStr
private String email;
@UserNameStr
private String userName;
On this page you can see a screenshot of the validation result when
the two constraints are violated:
http://code.google.com/p/axon-auction-example/wiki/ClickClient
The same constraints are used to validate the command on the server.
Of course this is just one example how you can do the client side
validation.
this is cool… and agree however I think this is a very repetetive infrastructure type item which could be valuable in the framework. Thats the point I was trying to make. The only nice to have would be the contract.requiredvalid could thow a constrainviolation like api standards exception with a set of constraint violations. Than it woule be even cooler because the client could arrange the exception closer to the fields for form input type commands or translate them to their UI specific messaging if they want to.
Agree with your thesis above and thanks for the insight.
Cheers…
Quote: I think this is a very repetetive infrastructure type item which could be valuable in the framework. Thats the point I was trying to make.
I think we agree on this point. but how could Axon make this easier, given the current feature to add interceptors to the command bus? What would you expect there? A concrete JSR303 bean validation interceptor? Or were you thinking of something else?
Cheers,
Allard
A JSR303 standards based infrastructure would be ideal for Java developers?
Thanks…