In my talk about event design in service oriented architectures I dicussed how you should try to design your events so that they would only carry Id's across service boundaries. Instead you would use use commands, which always are internal to a service, to store what ever data you need for each particular service and use the event to synchronize status changes across services. In essence this means that the only thing that is shared between services is the ID. This obviously also relates to how you design you entities. I'm not going into details here because Ayende has posted two excellent post on this subject. So please head over to his blog and read them:

http://ayende.com/blog/153703/there-ainrsquo-t-no-such-thing-the-definitive-entity-definition

http://ayende.com/blog/153704/composite-entities

As you see avoiding logical coupling between both events and entities is one of the most important things to think about when designing distributed systems that you don't expect to rewrite from scratch every other year.

Finally this also shows why trying to design a "canonical data model" for your entire system is such a bad idea. Doing this will send you straight down the road of failure.