CQRS Commands and Events as generic classes?
hothi...@googlemail.com
In most examples I saw, commands and events are represented as classes. That means you have to write a CorrectNameCommand class with name property and a NameCorrectedEvent class with name property. Given that both commands and events are serialized and deserialized in most cases and send to other parties (there goes the compile time type safety), what is the advantage of this explicit classes over a more generic class?
Example:
A Command class with a Name (that represents the type of the command), the key of the ag that should handle the command and an array of objects or name/value pairs for any other parameters.
An Event class essentially the same (perhaps we can put the shared parts in an CommandEventBase class).
The command (and event) handlers have now to check the name of the command (event) instead of its class type and have to rely on the correctness of the parameters in the list (like the deserializer has to rely that the serialized format is correct).
Is that a good approach? If yes, why is it not used in the samples and tutorials? If not, what are the problems?
Greg Young
Weak/hybrid serialization is better for versioning.
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Studying for the Turing test