That is one issue, as the number of services needing a model increases, you end up repeating this. It also becomes more complex as your domain grows and the c

That is one issue, as the number of services needing a model increases, you end up repeating this. It also becomes more complex as your domain grows and the complexity / number of events increases. Finally it can introduce a high degree of coupling, which ironically is something event modeling hopes to decrease. In this case if you have 5 or 6 consumers all building their own read model, but relying on specific events, the consumers are more deeply coupled into the services that emit these events. They now all need to be updated if something fundamental changes in the systems supplying events. I'm our case we used two techniques to mitigate this: - defined 'public' events with a clear api. These are the only events any external consumer should consume. Yes, it introduces some versioning ave migration issues, but also creates a clear and very helpful boundary. - defined read model as it's own domain and gave it a service. This is not always usable, but in many cases the model clients need of the entire system is fairly standard. This way they can integrate with a more typical query to pull the model rather than building it from scratch