I was wondering what solutions people have come up with to route commands that are protobuf types to the AR. The CommandTargetResolver gives you the command payload, and from there on you’ld have to extract for each command the aggregate id and version that this command should be routed to. So far we have not found a really elegant solution for this, other than trying to structure the syntax and naming of the each command so we can find these fields more easily via the protobuf metadata api. Using a protoc plugin one would probably be able to annotate the protobuf types with @TargetAggregateIdentifier but that’s a bit out of our competence area (let alone if it would actually be a good idea or not).
My first hunch would be to annotate your protobuf types like you suggest at the end.
I’ve done something similar in another project to have our own form of annotation on protobuf messages which seemed doable to me.
If you’d rather not take that route, the other thing that springs to mind is to introduce your own CommandTargetResolver, which based on your protobuf types knows were to pull the aggregate id and version from.
I’ll give it some more thought though, I’ll keep you posted.
Thanks for your thoughts Steven. We actually do have a CommandTargetResolver for the moment, it’s just that it needs to know for every single command class how to extract the aggregate id. This works but it’s a bit strange. I would be interested to hear how you created the protoc plugin to annotate the protobuf type attributes, was this a pure java plugin ?
So I took a look at our protobuf schema’s, but sadly however I have to disappoint you…
We’ve got a custom extension which introduces an extra field option we can place in our protobuf schema’s (which give us some form of annotation on the fields of a message).
Additionally I thought the effort was put in to let that generate actual Java annotations as well.
That’s however not the case, so I can’t give you a clear example of how that would be done…so sorry again to give you false hope I’d have a solution for you.
Good to hear you were already using your own CommandTargetResolver, but like you share that doesn’t change the fact it has to be aware of every single command class :-/
I’ll give this some thought, maybe I can come up with something else for you.
you might want to consider using a ‘convention over configuration approach’. Your CommandTargetResolver could use a Class->Property mapping, but only for exceptions to a rule. Since protobuf numbers all fields and I believe their API allows you to retrieve data based in this number, you could use the convention that field 1 (I believe numbering is 1-based?) contains the aggregate identifier.
I am doing this out of the top of my head, so I might be wrong with this, but it may prove worthwhile.