I have three bounded contexts: Users (generic subdomain), Groups (supporting subdomain) and Events (core domain). Basically users can create/join groups, create events within those groups, and sign up for events within group. This is for educational purposes, probably Users and Groups should be merged into one context. Anyway I need following read models:
- group with list of all members and all active events (requires "data" from Users, Groups and Events)
- event with list of all signed up group members (requires "data" from Events and Users)
The Users context is needed to get user profiles info for example.
So my idea is to have single separate project/microservice from those three bounded contexts that will have all read models needed by the UI. It will subscribe to domain events from all three contexts to build the read models. Is it a good idea?
On one side read model is kind of separate bounded context needed by the UI. On the other side it's a place which can cause some "conflicts" between teams working on other contexts, because they will want to update read model(s) according to their changes in bounded contexts.
The other approach (which I was using so far) is to have "smaller" read models in each bounded context / service, expose them through some API and use view-composition in API gateway level to build view models required by UI. However this is coupling all contexts/services and make the read model dependant on other services availability.
So it's very tempting to have one autonomous read model, independant from anything (only asynchronically on domain events).